This is the mail archive of the
mailing list for the newlib project.
Re: HEADSUP: Extended locales and removing __part_load_locale
On 07/13/2016 12:27 PM, Corinna Vinschen wrote:
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.
On Jul 13 12:01, Craig Howland wrote:
On 07/13/2016 11:31 AM, Corinna Vinschen wrote:
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.
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
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
...it *is* externalized via ctype.h macros. Without these macros
we wouldn't have this backward compat problem, at least in Cygwin.