Re: %ls and %lc in scanf.c

["J. Johnston" <jjohnstn at redhat dot com>]

Artem B. Bityuckiy wrote:
> Hello.
>
> J. Johnston wrote:
>
> > Artem B. Bityuckiy wrote:
> >
> > > Hello,
> > >
> > > We've added widechar support to vfscanf - %S, %ls, %C, %lc modifiers. 
> > > The code was given from FreeBSD's vfprintf.c - since
> > > Newlib's license is BSD, I think this is legal.
> > >
> > > The patch was tested a little bit - with default locale and 
> > > UTF8-based locale. If mbsrtowcs and mbrtowc work well, this should 
> > > work too.
> > >
> > > One issue that I've met - '#ifndef CYGNUS_NEC' macro that surrounds 
> > > __srefill function. I've added it to %C and %S-related code 
> > > (analogiously as it is in %c and %s-related code) but not sure if 
> > > this is correct.
> >
> > I am looking into the CYGNUS_NEC references.
>
>
> It would be fiene if you add comment about this macro usage somewhere :-)

The code and the macro references can be removed.

> > Is there any reason why you didn't segregate the code under the 
> > MB_CAPABLE macro like you did recently for vfprintf.c?  It would make 
> > sense to do it in conjunction with this change.
>
>
> Do you mean why I don't exclude %ls and %lc at all if MB_CAPABLE is 
> undefined? If so, my answer is - because in this case Newlib still 
> support widechar (but widechar is always US-ASCII expanded to 
> sizeof(wchar_t)) and possibility to onput/output widechar strings is 
> still actual.
>
> If you mean why I didn't segregate the code inside of %ls and %lc 
> handling code, my answer is: if MB_CAPABLE is undefined %ls and %lc 
> modifiers are used rarely and I didn't want to block up th code (just 
> for readability). Do you think this should be done? If so, no problems, 
> I can do this.

You might as well be consistent with vfprintf.c.  The usage of %ls and %lc might 
not be used readily for new code for a particular platform, but you can never 
guess what an application that you wish to port is going to do.

> > I also notice a number of formatting changes where the only change is 
> > moving the opening braces.  Is this due to your original code base?
>
>
> Hmm, do you mean that code like this
> if (a)
> {
>    b();
> }
> is changed to:
> if (a) {
>    b();
> }
> somewhere?
>
> I don't like the second style but this changes was done just not to mix 
> two styles. %ls and %lc support code uses the second style and where 
> this code is adjoining to Newlib's code, styles are aligned. Since there 
> is no one standard style in Newlib, I think the presence of several 
> styles is normal, but if the blocks with different styles are large it 
> will be better than the mix of smaller blocks.

The general rule should be: new code should use the Gnu Coding standard.  Old 
code that is brought in will be in whatever standard it was written in.  It is 
best to leave it alone as much as possible so that it makes it easier to compare 
newer versions of the source vs the newlib code.  When making modifications, 
stick with the surrounding style ("when in Rome").  If adding a new function in 
a file, then it would be preferable to use the Gnu style but I can live with the 
original style used in the file.

-- Jeff J.
> > -- Jeff J.