This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]