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