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