Re: [PATCH v2] Add __pure2 to __locale_ctype_ptr(_l)

[Corinna Vinschen <vinschen at redhat dot com>]

On Nov  7 20:37, Sebastian Huber wrote:
> ----- Am 7. Nov 2017 um 17:39 schrieb Wilco Dijkstra Wilco.Dijkstra@arm.com:
> 
> > Craig wrote:
> > 
> >> All of this might be moot due to pure2 appearing to not be valid for the general
> >> __locale_ctype_ptr case.  (Even if it would be safe for the specific test cases
> >> being discussed.)
> >> Would you please comment on those concerns?
> >> (https://sourceware.org/ml/newlib/2017/msg01055.html in case it did not make it
> >> to you originally.)
> > 
> > I don't understand your concern. This is how ctype works, GLIBC uses the same
> > attribute.
> > You inline the ctype lookup but (for various reasons) may want to hide the ctype
> > pointer
> > behind an expensive function call. The call must be marked in such a way that it
> > can be CSEd
> > and lifted out of loops. If you didn't want this to happen there would be no
> > point in providing
> > complex headers with inline functions for ctype.
> 
> Why don't we make
> 
> const char *
> __locale_ctype_ptr (void)
> {
>   return __get_current_locale ()->ctype_ptr;
> }
> 
> inline?
> 
> Why do we need the condition in:
> 
> _ELIDABLE_INLINE struct __locale_t *
> __get_current_locale (void)
> {
>   return _REENT->_locale ?: __get_global_locale ();
> }
> 
> Can't we set _REENT->_locale to &__global_locale instead of NULL?

_locale is NULL by default, as set by _REENT_INIT.  If you want to set
it to &__global_locale, you have to make sure reent's are initialized
correctly.  You also have to change _uselocale_r which relies on _locale
being NULL to denote using the global locale.  You also have to include
the definition of `struct __locale_t' into all affected headers, here
especially ctype.h.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

Attachment: signature.asc
Description: PGP signature