This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: codeset problems in wprintf and wcsftime
Corinna Vinschen wrote:
> On Apr Â2 20:09, Andy Koppe wrote:
>> I think there's another issue here. Since _ctype_locale_buf is meant
>> to be filled from a text file in non-Cygwin systems, the mb_cur_max
>> char would be an ASCII digit rather than a binary one, so that needs
>> to be accounted for:
>>
>> return __get_current_ctype_locale ()->mb_cur_max[0] - '0';
>
> No. ÂSee lmonetary.c.
But that's got the M_ASSIGN_CHAR macro and cnv function for converting
ASCII numbers in the locale file to binary. I can't see anything
similar for mb_cur_max.
>> And one more: __mb_cur_max is still being defined for systems with
>> __HAVE_LOCALE_INFO__, even though they'd no longer use it. Although,
>> since we're still using the global __mbtowc and __wctomb variables,
>> can't we just continue to use __mb_cur_max as well as __locale_charset
>> rather than go through __get_current_ctype_locale()?
>
> __mb_cur_max is defined for *all* systems. ÂIt has to be kept in sync
> for applications which have been built using the old definition of
> MB_CUR_MAX.
Makes sense.
> ÂThe global variables
> __mbtowc and __wctomb are supposed to be stored in the locale_t
> structure at one point as well, even on systems only supporting a single
> locale_t.
So why not treat __mb_cur_max and __lc_ctype_charset the same way?
Global now, part of locale_t later.
>> > No, that spoils the way the data is read from locale files. ÂFor
>> > Cygwin that would be no problem, but it doesn't match the way the
>> > __part_load_locale function works.
>>
>> I see, but it seems a shame to fit everything around the needs of the
>> input function, rather than make the input function convert to a
>> format that's best for the rest of the program. I fear those extra
>> indirections will cancel out much of the work you previously did to
>> speed up multibyte conversion.
>
> I don't think so. ÂExcept for iso and cp functions, the other functions
> don't need to access the locale info a lot.
They may not actually need it, but the likes of mbrtowc() and
wcrtomb() all call __locale_charset() anyway. And if that does an
additional function call and pointer access, that's gonna make a
difference.
> Yes, that's broken. Â__part_load_locale still needs some work, but I
> didn't consider this important as long as nobody is actually using it.
Alright, so newlib's on-disk locale format essentially is still undefined?
Andy