[PATCH v2] Add __pure2 to __locale_ctype_ptr(_l)

Sebastian Huber sebastian.huber@embedded-brains.de
Tue Nov 7 21:29:00 GMT 2017

----- 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;


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?

Systems using __getreent() would probably benefit from a __pure2 attribute.

More information about the Newlib mailing list