[PATCH][STEP 3]remove access of locale

[Eric Blake]

On 02/09/2018 09:13 AM, Jaap de Wolff wrote:
> The functions that can be used to create or modify locales are adapted.
> Functions to create or duplicate a locale are returning NULL now.
> Should they also set an errno?

Yes.

> And if they should, what errno should they set?

>   _duplocale_r (struct _reent *p, struct __locale_t *locobj)
>   {
> +#ifdef _REENT_SMALL
> +	return NULL;

This should set ENOMEM (conceptually, we're so small that ALL attempts 
to create a locale are beyond the memory limits we have available ;)

By the way, POSIX says duplocale returns '(locale_)0' on failure; you're 
lucky that NULL works here because our locale_t is a wrapper around 
'struct __locale_t*'.


>   _newlocale_r (struct _reent *p, int category_mask, const char *locale,
>   	      struct __locale_t *base)
>   {
> +#ifdef _REENT_SMALL
> +	return NULL;
> +#else	

ENOMEM is also appropriate here

> +++ b/newlib/libc/locale/setlocale.h
> @@ -209,15 +209,23 @@ extern size_t _wcsnrtombs_l (struct _reent *, char *,
> const wchar_t **,
>   _ELIDABLE_INLINE struct __locale_t *
>   __get_global_locale ()
>   {
> +#ifdef _REENT_SMALL
> +  return NULL;

I'm not sure how this internal function will affect things, or whether 
it should return NULL. Ideally, in a small compilation environment, we 
shouldn't even be dereferencing __get_global_locale because we should 
already know things are hard-coded; if it does dereference NULL, you 
have a problem.  So do you really want _REENT_SMALL code here, or is it 
better to omit the function entirely?

> @@ -276,14 +288,18 @@ __get_current_ctype_locale (void)
>   _ELIDABLE_INLINE int
>   __locale_mb_cur_max_l (struct __locale_t *locale)
>   {
> +#ifdef _REENT_SMALL
> +	return 2;

Why 2?  The "C" locale should return 1, and if you aren't supporting 
locales, you shouldn't have any multi-byte sequences longer than 1.


-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org