Created attachment 4412 [details]
Test case.

Not everything that is possible to do should be done.  Why on earth is this needed?

Note that locale.h description says that LC_GLOBAL_LOCALE is a special value for
use by the uselocale function.  There is nothing that says it can be used in
other functions.  If you want to query the global locale, why don't you just use
nl_langinfo instead of nl_langinfo_l?
You'd be requesting that isdigit_l (x, LC_GLOBAL_LOCALE) works next time, all
those macros/inclines then would need to special case that value.

It's sometimes useful to have code that treats `LC_GLOBAL_LOCALE' like any other
locale object.

The wording at
http://www.opengroup.org/onlinepubs/9699919799/basedefs/locale.h.html suggests
that it's a "locale object descriptor", which should be usable with any function
that takes a locale object descriptor, not just uselocale(3).

(In reply to comment #4)
> It's sometimes useful to have code that treats `LC_GLOBAL_LOCALE' like any other
> locale object.

It's complete nonsense in this case and prohibitively expensive in some other
cases.  I won't change this.  And since the specification is written after the
glibc implementation it has to be adjusted.

(In reply to comment #3)
> If you want to query the global locale, why don't you just use
> nl_langinfo instead of nl_langinfo_l?

Note that the proposed

  nl_langinfo_l (item, LC_GLOBAL_LOCALE)

is not equivalent to

  nl_langinfo (item)

but rather to

  ({ locale_t old_thread_locale = uselocale (LC_GLOBAL_LOCALE);
     const char *value = nl_langinfo (item);
     uselocale (old_thread_locale);
     value;
  })

or to

  ({ locale_t global_locale = duplocale (LC_GLOBAL_LOCALE);
     const char *value = nl_langinfo_l (item, global_locale);
     freelocale (global_locale);
     value;
  })

But I agree with your evaluation that it is not essential to support
LC_GLOBAL_LOCALE arguments here (unlike in duplocale, see bug10969).

I'm reopening this because it bites users all the time. We do a terrible disservice by not returning real locale_t objects from uselocale under all conditions.

I don't see that it would be that hard to make LC_GLOBAL_LOCALE a real object instead of (locale_t) -1, and it would make the API easier to use.

There have been no technical arguments against this, and it would increase the QoI to be able to do this:

  myloc = uselocale ((locale_t) 0);

And then later use myloc for any API that needs a locale_t object.

Someone would have to present a strong performance argument to convince me that this was prohibitively expensive to make the API accessible to everyone.