swprintf() and friends?

[Corinna Vinschen]

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