This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: [PATCH v2] Add __pure2 to __locale_ctype_ptr(_l)
----- 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?
Systems using __getreent() would probably benefit from a __pure2 attribute.