Re: POSIX gettext() and uselocale()

[shwaresyst]

Historically, gettext domains are process wide, making use in multi-threaded apps problematic to begin with. The *_l versions only partially address this. The uselocale() interface is included there for the cases where a locale is used by both a uselocale() and one or more of the *_l versions, in that a second uselocale() call after the retrievals, with a different locale, may cause the memory mapping many implementations use for .mo files to be released on the next *_l call. Yes, it is not the call itself that causes these releases, or shouldn't, but as the root reason, imho, it should stay in the list.

On Sun, Jan 16, 2022 at 4:11 PM, Bruno Haible via austin-group-l at The Open Group

<austin-group-l@opengroup.org> wrote:

[First sent on 2021-05-03. Resending because it has not been handled.]

https://posix.rhansen.org/p/gettext_draft
says (line 358):

  "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()."