Re: HEADSUP: Extended locales and removing __part_load_locale

[Corinna Vinschen <vinschen at redhat dot com>]

On Jul 13 12:01, Craig Howland wrote:
> On 07/13/2016 11:31 AM, Corinna Vinschen wrote:
> > 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
>      Couldn't you just use a similar method as with impure_ptr (_REENT)?
> (That is, turn the pointer into a function which returns the present
> pointer.)  That could keep backwards compatibility in case someone is using
> it with the current method, but is not on the mailing list to be able to
> reply.

We need a function call, it doesn't matter how it's called.  The only
problem is if some target needs to maintain backward compat with older
applications compiled under a previous version of newlib, because...

>      From a different perspective:  __ctype_ptr__ is an internal
> implementation detail.  (It only appears under libc/ctype and
> libc/include/ctype.h, not anywhere else in newlib or libgloss.) People
> should not be using it directly, so if it gets changed and such a use breaks
> something, they get to re-do what they should not have done in the first
> place.

...it *is* externalized via ctype.h macros.  Without these macros
we wouldn't have this backward compat problem, at least in Cygwin.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

Attachment: signature.asc
Description: PGP signature