Re: HEADSUP: Extended locales and removing __part_load_locale

[Corinna Vinschen <vinschen at redhat dot com>]

Hi guys,


Along these lines:

The ctype functions and macros use the global variable __ctype_ptr__.
That's not feasible anymore with POSIX locales which require a function
returning the current locale's ctype array pointer (we should have done
that from the start, duh!)

Apart from Cygwin, do we have a target which has to keep the global
__ctype_ptr__ for backward compat?  If not, I'll remove it in favor of
the per-locale ctype pointer.


Thanks,
Corinna


On Jul 11 14:59, Corinna Vinschen wrote:
> Hi folks,
> 
> tl;dr:  I'm planning to remove the __part_load_locale function and
>         remove all calls to it because this code never worked.
> 
> Long story:
> 
> I've started to work (slowly!) on POSIX-1.2008 style locale support,
> which means per-thread locales and the FOO_l functions.  While looking
> into the existing code, I stumbled over the fact that __part_load_locale
> has a major bug in the locale buffer handling and could never really
> work as intended.
> 
> Typically small targets only have minimal locale support, i.e.  setting
> LC_CTYPE and LC_MESSAGES works but nothing else.  Those don't use
> __part_load_locale.  Same for Cygwin since Cygwin uses Windows locals
> under the hood.
> 
> However, every other target using newlib's *extended* locale support
> (#define __HAVE_LOCALE_INFO__) is and always was broken.
> 
> So, does anybody here actually use Newlib's setlocale *and* has
> __HAVE_LOCALE_INFO__ defined, outside of Cygwin?
> 
> If so, please speak up.
> 
> Otherwise, I'll remove __part_load_locale and the code calling it in the
> next couple of days.
> 
> I'll be already busy enough to do the groundwork and eventually to add
> the necessary changes to Cygwin.  For everything else we will need a
> volunteer.

Attachment: signature.asc
Description: PGP signature