Jaromír Dolecek wrote about Re: -current setlocale() problems:
:Geoff Wing wrote:
:>         printf("%s\n", setlocale(LC_ALL, ""));
:>         printf("%s\n", setlocale(LC_ALL, NULL));
:> OK, now the first line should be "(null)" and the second should be "C",
:> right?  What is this stuff being spewed out?  Why did the locale change
:> succeed?
:AFAIK first sets environment to "native" one. If LANG nor LC_ALL
:is set, this means "C". So the result you've got is correct AFAICS.

Yes, the default was correct.

:If LANG/LC_ALL is set to some bogus value and it still succeeds,
:it's an error. Itojun made couple of fixes to LC_CTYPE loading
:so that it returns failure as appropriate, you might want to update
:to up-to-date sources and try again.

I wrote:
:during -current setlocale() changes (24th Dec):

Well, I'm up-to-date as of today (setlocale.c is 1.30) and I haven't seen
anything over source-changes indicating anything's changed today.

The string "C/foobar/C/C/C" is the slash-separated concatenation of
    LC_COLLATE LC_CTYPE LC_MONETARY LC_NUMERIC LC_TIME
from the call to currentlocale() at the end of setlocale().  That's
still weird to me though maybe it's normal?

If you change the source to use LC_CTYPE instead then you'll just get
the CTYPE, but it'll spew out "foobar" as if it succeeded.  The error
states and actions upon error are not working.

If nobody else (who has been working in that area) has looked at it in
the next couple of days, I'll come up with a fix and send-pr it.

Regards,
-- 
Geoff Wing : <gcw@pobox.com>
Rxvt Stuff : <gcw@rxvt.org>
Zsh Stuff  : <gcw@zsh.org>