vfprintf multibyte

J. Johnston jjohnstn@redhat.com
Mon Nov 24 15:15:00 GMT 2003


Thanks Artem.  There was an error in your non-mb-capable version of positional 
arguments but I have fixed that and checked your patch in with a few other minor 
tweaks.

-- Jeff J.

Artem B. Bityuckiy wrote:
> 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.
> 



More information about the Newlib mailing list