Some 4.0 portability problems.

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Some 4.0 portability problems.

Michael T. Richter-2
I'm trying to port Lua 4.0 over to Windows CE and have come across a few
problems.  These are mainly related to encapsulation issues.  Specifically,
file handling is mostly encapsulated within the ZIO library, but there's a
single location which does file handling without ZIO that's causing me some
grief.

The function parse_file in ldo.c makes use of raw buffered I/O (fopen,
freopen, etc.) instead of ZIO.  Worse, it makes use of freopen, a function
which only makes sense if you're in an environment which has consoles and
the like.  Windows CE, of course, being a handheld, pen-based device doesn't
have consoles.  Had the work in parse_file been through the ZIO library, I
could have mocked up stdin, stdout, stderr and abstracted them away behind a
hacked ZIO version.  Unfortunately the calls are made directly, thus
requiring me to hack up core Lua source code.

Would it be possible to persuade the powers that be to make use of ZIO only
when doing file I/O in future Lua versions?

--
Michael T. Richter
"Be seeing you."


Reply | Threaded
Open this post in threaded view
|

Re: Some 4.0 portability problems.

Luiz Henrique de Figueiredo
>file handling is mostly encapsulated within the ZIO library, but there's a
>single location which does file handling without ZIO that's causing me some
>grief.

ZIO is just a uniform interface for reading bytes transparently from files,
strings and byte arrays.
However, in the case of files, it ZIO them to be opened first and we left
this to the user. Moreover, in the case of Lua, we have to look into the files
to see whether they contain Lua source or Lua precompiled chunks. That's
why we need freopen and why parse_file in ldo.c is complicated.
How would you change parse_file?

I agree that stdin, stdout, stderr only make sense for environment that
have consoles. but not about freopen. Am I missing something?

Anyway, the bottom line is: does Windows CE implement stdio from ANSI C?
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: Some 4.0 portability problems.

Michael T. Richter-2
----- Original Message -----
> ZIO is just a uniform interface for reading bytes transparently from
files,
> strings and byte arrays.
> However, in the case of files, it ZIO them to be opened first and we left
> this to the user. Moreover, in the case of Lua, we have to look into the
files
> to see whether they contain Lua source or Lua precompiled chunks. That's
> why we need freopen and why parse_file in ldo.c is complicated.
> How would you change parse_file?

I would make ZIO a beefier abstraction of stream handling which dealt with
opening files, etc. as well as its current duties.  This way all the work
for handling non-ANSI file I/O can be done in one location instead of
searching around throughout the code.  For example, in Win32 in general
calling the native APIs for file I/O is more efficient than calling the ANSI
ones.  I could, for example, make file I/O much more efficient by, say,
using overlapped I/O calls.  I can't do this with the ANSI APIs.  If all of
the stream I/O (file or otherwise) was localized within a single
subcomponent, I could -- no matter what the platform -- optimize stream I/O
handling using whatever special tools the underlying platform provides.  And
in cases where the underlying platform doesn't supply particular
functionality (freopen being a case in point), I can fake it using whatever
facilities are actually available.

> I agree that stdin, stdout, stderr only make sense for environment that
> have consoles. but not about freopen. Am I missing something?

Freopen is typically used to redirect stdin, et al in my experience and I
made the unwarranted leap that this is what you were doing here.  Later
inspection proved that wrong and I replaced the call to freopen with an
fclose followed by an fopen.

> Anyway, the bottom line is: does Windows CE implement stdio from ANSI C?

Only partially.  This is why I'm always an advocate of abstraction layers
when writing code.

--
Michael T. Richter
"Be seeing you."