This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: swprintf() and friends?
On Nov 3 16:26, Jeff Johnston wrote:
> Corinna Vinschen wrote:
>> Jeff, where would you put the fwide flag (at least two bytes)? In
>> struct __sFILE64 it would fit into _flags2, but where should they go in
>> struct __sFILE? Or would it make sense to support wide IO only on
>> platforms using __LARGE64_FILES?
>
> Adding additional fields to __sFILE and __sFILE64 should be ok and no, I
> wouldn't just support wide I/O only on large files.
When using shared libs it might a problem if an application compiled
with an older version of newlib is juggling FILE structures by itself.
I don't know if there's any application actually doing that and what
it's suposed to accomplish, though. Fortunately __sFILE64 has the
free _flags2 so it doesn't matter for Cygwin.
> I would start by adding a _flags2 field in a regular __sFILE which makes it
> consistent with __sFILE64. This will be outside of the fake std stream
> support. Anything that can be checked on a non-resolved fake std stream
> "has" to be in _flags. This includes operations where we don't want to
> resolve the stream (e.g. checking the error or EOF flags). After that, it
> is optional where a flag goes.
>
> At quick glance, the __SMOD flag can definitely be moved to _flags2 as it
> is never set in newlib code and never checked except by fseek and only
> after resolving any std stream. I assume it is a Cygwin creation as it was
> added by cgf in 2000 for fgetline.c which doesn't exist in newlib. If
> this is not used by Cygwin, we should toss it altogether. Either way, it
> frees up one bit.
It's not used anywhere in Cygwin and Cygwin doesn't have any fgetline
function or fgetline.c file. I don't know what the original idea was
back then. Chris?
> For fwide support, I assume you mean two bits and yes, I believe two bits
Oh, sure, two bits. Sorry.
Corinna
--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat