Re: Some 4.0 portability problems.

["Michael T. Richter" <mtr@...>]

----- 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."