[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
POSIX gettext() and uselocale()
From: |
Bruno Haible |
Subject: |
POSIX gettext() and uselocale() |
Date: |
Tue, 04 May 2021 01:07:39 +0200 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-206-generic; KDE/5.18.0; x86_64; ; ) |
https://posix.rhansen.org/p/gettext_split
says (line 92):
"The returned string may be invalidated by a subsequent call to
bind_textdomain_codeset(), bindtextdomain(), setlocale(),
textdomain(), or uselocale()."
While in most programs setlocale(), textdomain(), bindtextdomain(),
bind_textdomain_codeset() are being called at the beginning of the
program execution, before any call to gettext(), the situation is
very different for uselocale().
1) uselocale() is meant to have effects ONLY on the thread in which it
is called.
2) uselocale() is a helper function to implement *_l functions where
the POSIX standard does not specify them or the system does not have
them.
For example, when a program wants to have a function to parse
a number, recognizing only the ASCII digits and only '.' as decimal
separator, a reliable way to implement such a function is by calling
uselocale of the "C" locale, strtod(), and then uselocale() again
to switch the thread back to the previous locale.
If POSIX did not have uselocale(), it would need to provide many
more *_l functions.
If the gettext() result may be invalidated by a uselocale() call (in
any other thread!), this would mean that
** Programs can use gettext() or uselocale() but not both. **
and - more or less -
** Multithreaded programs that use libraries (that may use uselocale())
cannot use gettext(). **
I think that specifying gettext() to be so restricted is not useful.
It would make more sense to allow concurrent uselocale() calls.
Proposed wording:
"The returned string may be invalidated by a subsequent call to
bind_textdomain_codeset(), bindtextdomain(), setlocale(),
or textdomain()."
Bruno
- POSIX gettext() and uselocale(),
Bruno Haible <=