Re: CVS commit: src/lib/libc/locale
On Tue, Apr 16, 2013 at 04:55:01AM +, YAMAMOTO Takashi wrote: hi, On Mon, Apr 15, 2013 at 11:40:57PM +0900, Takehiko NOZAKI wrote: POSIX2008 spec say, *_l func with invalid locale handle may EINVAL. NULL or (locale_t)0 is invalid locale handle. why are you think fallback to C locale? That's what Apple and FreeBSD provide and which is actually quite useful. Wanting access to the C locale is the most common case for many locale issues. Making that easy sounds like a good idea in general. is there consumers of this extension in the field? Yes. an application can have a global c_locale = newlocale(C) if it wants an easy access to the C locale. ...which means keeping a copy around in various libraries etc. It is possible, but wastes memory. Joerg
Re: CVS commit: src/lib/libc/locale
On Tue, Apr 16, 2013 at 11:39:50PM +0900, Takehiko NOZAKI wrote: before implementing such non-portable *broken* stuff. At the very least it is a conforming extension. ...which means keeping a copy around in various libraries etc. It is possible, but wastes memory. most of application in the world doesn't require multi-locale stuff. so that the struct _locale __C_locale in libc is much more wasteful. Most applications can/should enable the user locales. That means that as soon as they also have to deal with accessing data from non-internalized sources, they have to deal with both the user and the C locale. The very same reasoning applies to libraries. Joerg
Re: CVS commit: src/lib/libc/locale
On Tue, Apr 16, 2013 at 11:39:50PM +0900, Takehiko NOZAKI wrote: That's what Apple and FreeBSD provide and which is actually quite useful. useful? don't say that. I have heard same word from who spreads broken iconv(3) usage, (such as non-portable //TRANSLIT features that annoying pkgsrc peoples). http://mail-index.netbsd.org/tech-userlevel/2006/04/03/.html //TRANSLIT is quite a different deal because it is a workaround for the bad default behavior of GNU iconv... Joerg
Re: CVS commit: src/common/lib/libc/stdlib
On Tue, Apr 16, 2013 at 07:34:58PM +, Joerg Sonnenberger wrote: Module Name: src Committed By: joerg Date: Tue Apr 16 19:34:58 UTC 2013 Modified Files: src/common/lib/libc/stdlib: _strtol.h _strtoul.h Log Message: Do not use isalpha here, since we explicitly only support the Portable Character Set as base and in theory a locale could define a ASCII control character as letter, resulting in negations. Also avoid isdigit here to give the compiler a better chance of deciding whether an unsigned compare or a jump table is a better option, both are very likely better choices than the memory indirection. There really ought to be a way of requesting the straight ASCII versions of the is functions even after a local has been set. A lot of code will use isalpha() to check for valid variable names (etc) and really doesn't want locale-specific alpha characters be valid. (Otherwise scripts become non-portable.) OTOH (unsigned)(ch - '0') = 9 is probably the fastest isdigit() on any modern cpu. David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/lib/libc/locale
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. YAMAMOTO Takashi
