%S %C vfprintf contribution

J. Johnston jjohnstn@redhat.com
Mon Nov 10 09:59:00 GMT 2003


Artem B. Bityuckiy wrote:
> Hello Jeff!
> 
> J. Johnston wrote:
> 
>> Artem,
>>
>>   A number of comments/issues:
>>
>>   1. The tests for buf size vs MB_LEN_MAX shouldn't be needed.
>>      The lowest value is 40 and I don't think I want to see a character
>>      set that requires over 40 bytes to encode a single character. :)
> 
> 
> I don't think it is an error - it is just paranoid check. Theoretically, 
> MB_LEN_MAX may be > 40 (I think only about variable rang - not about 
> real multibyte characters). This is preprocessor check an it doesn't 
> make much overhead. :-) Please, remove this if you consider necessary.
>

It messes up the readibility of the code for no gain so I prefer to leave it out.

>> 2. Your 'S' code ends up falling into the old strlen check for 's'.  You
>>      should prevent this by using an else clause.
> 
> 
> Hmm, I think you missed about 'break' at line 728...
>

Yes I did.  It would be much clearer if it was done with if/else logic.  At the 
very least a comment after the widechar code is in order that explains "if you 
are here then the following xxxx is true".

>>   Your check for cp is
>>      NULL should occur at the top just after setting cp.  Your S code can
>>      then be an else if and the old 's' code can be in an else clause.
> 
> 
> If cp is NULL we consider this as if it was called with %s and set it to 
> "(null)". (This means, treat calls vfprintf("%S", NULL) = vfprintf("%s", 
> NULL)). In both cases "(null)" string will appead in file stream. Ther 
> is a check for cp != NULL at line 678. Is this an error?
> 

Nope, it was just to make things clearer.  In either case for a widechar or
non-widechar string, you have to check if the ptr is null and print "(null)".
You have added a large section of code specific to widechar in-between that has 
a null-check.  It is much clearer if you simply do the null case up front and 
then you don't have to check for null twice.

>>
>>   3. Your freeing of the widechar string buffer is not in the right spot.
>>      There is an error case that follows allocating the buffer so you 
>> won't
>>      free it.  
> 
> 
> Yes, you are right, I've missed this.
> 
>> You should also use a separate ptr other than cp for the
>>      malloc'd storage so there is no doubt you are freeing the right 
>> thing
>>      at the end.
> 
> 
> We are setting WIDECHARSTR flag only on line 719 after malloc. I think 
> it is no need to introduce another pointer.
> 

Actually, I would still prefer a separate pointer.  It prevents future changes 
from screwing up the free (e.g. somebody sets the flag too early on or in a 
different spot and cp has been incremented).  It also makes it easy to add other 
malloc'd storage as needed to other format specifiers and have a single free 
call that doesn't have to check for a specific flag.  The change I am asking for 
is trivial to do.

>>
>> -- Jeff J.
>>
>> Artem B. Bityuckiy wrote:
>>
>>> Artem B. Bityuckiy wrote:
>>>
>>>> Hello.
>>>>
>>>> Nicholas Wourms wrote:
>>>> > Artem B. Bityuckiy wrote:
>>>> >
>>>> >> Hello.
>>>> >>
>>>> >> Here is the patch that makes vfprintf (and hence, all other
>>>> >> vfprintf-based Xprintf functions) understand ISO C 90 %S (same as 
>>>> %ls)
>>>> >> and %C (same as %lc) format placeholders. Please, review it and give
>>>> >> us know if something is wrong.
>>>> >>
>>>> >> This is tested a little bit- it works and it seems should work with
>>>> >> any locale if wcrtomb and wcsrtomb functions work.
>>>> >>
>>>> >
>>>> > I believe the preferred patch type is unidiff or `diff -up`.
>>>> OK, here is the patch to vfprintf.c produced by diff -up.
>>>> >
>>>> > Cheers,
>>>> > Nicholas
>>>> >
>>>> Initially, we've added these changes to Newlib-1.11.0. They was 
>>>> tested with Newlib-1.11.0 too. But then I've copy changes to Newlib 
>>>> from CVS. vfprintf.c from CVS differs from Newlib-1.11.0's 
>>>> vfprintf.c. I didn't test (even compile) Newlib from CVS with these 
>>>> patch, but it must work.
>>>>
>>>> Thanks.
>>>>
>>>
>>
>>
> I've attached new diff -uN file.
> 



More information about the Newlib mailing list