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

[yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)]

> 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.

YAMAMOTO Takashi