vfprintf multibyte

[Artem B. Bityuckiy]

J. Johnston wrote:

> Artem B. Bityuckiy wrote:
>
>> Hello.
>>
>> I offer some optimization.
>>
>> Look at CVS-Newlib newlib/libc/stdio/vfprintf.c line 553 for example. 
>> mbtowc call is used. This is needed to support multibyte format 
>> string. But usually in newlib such things are placed in #ifdef 
>> MB_CAPABLE/#endif pair. And this is right because it excludes junk 
>> code if Newlib is configured without multibyte support (if MB_CAPABLE 
>> isn't defined then the only multibyte is US_ASCII or, possibly, other 
>> 1 byte encoding like iso-8859-x).
>>
>> I offer the patch that excludes mbtowc calls if newlib shouldn't 
>> support multibyte.
>>
>> Please, see, check, comment.
>>
>
> The non-mb code doesn't appear to handle the end of the format 
> string.  In the old code, there is a check if _mbtowc_r returns <= 0 
> at which point the code breaks.  For the nul terminator, _mbtowc_r 
> will return 0.  The replacement code  stops the loop when *fmt is '\0' 
> but it does not check it afterwards.  The code later makes the 
> assumption it is skipping over the format specifier (fmt++) when this 
> could well be the nul terminator.
>
> -- Jeff J.
>
>
>
>
Hello.
Corrected.
This time, I've tested vpfrintf with both --enable-newlib-mb=yes and 
--enable-newlib-mb=no
Tested by test from glibc-2.3.2.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: vfprintf.diff
URL: <http://sourceware.org/pipermail/newlib/attachments/20031121/c02a8166/attachment.ksh>