Re: swprintf() and friends?

[Jeff Johnston <jjohnstn at redhat dot com>]

Corinna Vinschen wrote:
> On Oct 31 12:26, Jeff Johnston wrote:
>   
> > Sam Clegg wrote:
> >     
> > > This question was asked back Feb but I couldn't see any responses:
> > >
> > > http://sourceware.org/ml/newlib/2008/msg00083.html
> > >
> > > Are there any plans to add swprintf?  Is is just a question of finding
> > > somebody or some time to implement it?
> > >
> > > cheers,
> > > sam
> > >   
> > >       
> > No, there are no "plans" to do this.  Yes, it is always a question of 
> > finding somebody to implement it :)
> >
> > If it is important to an application you wish to use right now with newlib, 
> > feel free to take a stab at implementing it.
> >     
>
> It's not only swprintf, but the whole lot of missing wide stdio functions
>
>   fgetwc
>   fgetws
>   fputwc
>   fputws
>   fwide
>   fwprintf
>   fwscanf
>   getwc
>   getwchar
>   putwc
>   putwchar
>   swprintf
>   swscanf
>   ungetwc
>   vfwprintf
>   vswprintf
>   vwprintf
>   wprintf
>   wscanf
>
> 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.

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.

For fwide support, I assume you mean two bits and yes, I believe two 
bits would work.  One bit would mean decided (0 = undecided) and this 
should take the free bit I mention above.  The __srefill_r and 
__sfvwrite_r functions could be modified to stamp a file as being 
narrow/wide and decided, if currently undecided (an extra argument would 
be needed to these functions to say which type of fn was calling).  If 
setting and the file is already undecided, then we must resolve any std 
stream first.  The decided orientation bit would be in _flags (0 = 
narrow, 1 = wide).

Mixing of narrow/wide functions is undefined behavior.

-- Jeff J.
> Corinna
>
>