Re: HEADSUP: Extended locales and removing __part_load_locale

[Corinna Vinschen <vinschen at redhat dot com>]

On Jul 13 12:44, Craig Howland wrote:
> On 07/13/2016 12:27 PM, Corinna Vinschen wrote:
> > 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.
> > 
> Sorry, I did not realize you were talking about dynamic backwards
> compatibility in this specialized sense.  So in the Cygwin type of
> application my latter point is not applicable.  But the _REENT/impure_ptr
> model still could be used to allow that type of compatibility.  My
> applications all get rebuilt for a new Newlib version, so I personally do
> not care, and I'd just as soon see a cleaner method instead of a more
> convoluted one for this limited backwards-compatiblity model.

I'm still hacking on this, but it seems sticking to the global
__ctype_ptr__ variable makes sense, not only for backward compat, but
for easier initialization as well.  My current sandbox code still uses
__ctype_ptr__ as global pointer and only uses a per-REENT ctype_ptr if a
per-REENT locale with a LC_CTYPE override has been defined.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

Attachment: signature.asc
Description: PGP signature