Re: CVS commit: src/lib/libc/locale

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Mon, Apr 22, 2013 at 01:45:52AM +0000, YAMAMOTO Takashi wrote:
> > On Thu, Apr 18, 2013 at 06:58:42AM +0000, YAMAMOTO Takashi wrote:
> >> > On Tue, Apr 16, 2013 at 11:34:52PM +0000, YAMAMOTO Takashi wrote:
> >> >> > On Tue, Apr 16, 2013 at 11:39:50PM +0900, Takehiko NOZAKI wrote:
> >> >> >> so that the struct _locale __C_locale in libc is much more wasteful.
> >> >> > 
> >> >> > I should add that it is an internal detail and the way the composed C
> >> >> > locale is stored can and likely will change later. So the way it is
> >> >> > essentially a copy of (old) global locale is just a way to be 
> >> >> > minimally
> >> >> > intrusive.
> >> >> > 
> >> >> > Joerg
> >> >> 
> >> >> i care the API.
> >> >> 
> >> >> if you really want it be in libc, how about having libc provide a
> >> >> "locale_t get_static_c_locale();" style API rather than using NULL?
> >> >> it's better because 1) less code in *_l, 2) autoconf-like can detect
> >> >> the extension easily, and 3) a portable application can trivially
> >> >> have a fallback implementation using newlocale+pthread_once.
> >> > 
> >> > It adds more cost on the caller side. So far, there are three mechanisms
> >> > available (especially for libraries):
> >> > 
> >> > (1) Adhoc access to internal locale state. This is used with glibc.
> >> > (2) Explicit newlocale().
> >> > (3) Implicit access via 0 argument to *_l.
> >> > 
> >> > The first one is clearly a hack and not acceptable. Portable code can
> >> > always conditionally use (2), but it requires additional setup and
> >> > storage cost. (3) is used by Apple (which is where a large part of the
> >> > *_l interface originates from) and FreeBSD. It is orthogonal to (2) and
> >> > certainly easier to use. Exposing it via a special library call is also
> >> > possible and effectively a way to implement (2) by a static wrapper.
> >> > It still adds more cost to every caller and this is a classic case where
> >> > there are typically much more callers.
> >> > 
> >> > Joerg
> >> 
> >> (3) adds small costs to every calls of *_l, even when the extension
> >> is not used.  i sounds worse than a one-time cost of (2) to me.
> > 
> > (2) still needs to load the address (instead of a constant), so it isn't
> > free either. Given that this is very popular as functionality and at
> > least on modern CPUs often implementable as conditional-move, it sounds
> > like a much better trade off.
> 
> very popular?  i'm not aware of a single software which uses this extension.
> can you provide examples?

The "very popular" specifically applies to the need for accessing the C
locale. Most bigger libraries need it one way or another. I am currently
talking with Apple about providing a visible macro (LC_C_LOCALE) to
address the testability issue.

Joerg