This is the mail archive of the
mailing list for the glibc project.
Re: The behavor of printing out libc message catalog without calling setlocale()
- To: drepper at cygnus dot com
- Subject: Re: The behavor of printing out libc message catalog without calling setlocale()
- From: GOTO Masanori <gotom at debian dot or dot jp>
- Date: Wed, 08 Nov 2000 03:40:48 +0900
- Cc: gotom at debian dot or dot jp, libc-alpha at sourceware dot cygnus dot com
- References: <firstname.lastname@example.org>
From: Ulrich Drepper <email@example.com>
Date: 07 Nov 2000 08:40:44 -0800
> > IMHO, it is inappropriate behavior that we must call
> > setlocale() in any case we have libc's translated .po file.
> > So, (3-1) or (3-2) is the best solution to fix it.
> First, you haven't said which version of glibc you are using. We had
> a change in this area lately.
Sorry. The version I mentioned was glibc-2.1.97, and the latest cvs snapshot.
> Second, calling setlocale() is always
> necessary if any of the locale-related environment variables is to be
> used (LC_ALL, LC_xxx, LANG).
What standard is it described?
If calling setlocale() is needed anytime when we set locale-related
env variables, we must write setlocale() into hello.c ?!
# Why don't you have setlocale(LC_ALL,"") in crt0.o? :-)
If we set the locale-related variables but a program does not
call setlocale(), it should work as same as LC_ALL=C. Unix98 said that:
For C-language programs, the POSIX locale is the default locale
when the setlocale() function is not called.
> This changed recently but only aligned
> glibc code with the behavior of gettext outside glibc (it was simply a
> bug). You seem not to like this but it is how it's supposed to work
> (it works just like catgets() with the NL_CAT_LOCALE flag set). You
> can even give reasons for this: a program must be able to say that it
> does not want any translations and this happens by not using
> Having said this, there is a loophole. If the user set the LANGUAGE
> environment variable the requested translation is always used. I'm
> not especially happy about this but don't see a way to not do this.
> Also, it might help in situations like yours.
I set only LANGUAGE=ja_JP.eucJP, the sample 1 and 2 program
which is written in my previous mail fail to print out Japanese
messages everytime (print out not "Success" or Japanese libc's
message catalog but "????").
I set LANGUAGE and LANG as ja_JP.eucJP, the sample 1 fails and
the sample 2 works.
Now, I found out the solution to fix this problem
(And I found my previous mail have some mistake):
A program which does not call setlocale() should not print out
any libc's translated message.
Current glibc write out translated messages whenever we do not
call setlocale(). It is not appropriate.
So, sample 2 program have to print out the message "Success"
in spite of I set LANG=ja_JP.eucJP, that is printed out same as
LANG=C environment. It may be needed to modify some code in intl/*.
-- GOTO Masanori