localeconv not working

php.internals

Klaus Reimer

21 years ago
Hello, I just notices that localeconv is not working properly (at least in PHP 5.0.2 and 4.3.9), it does not return the correct thousands_sep and decimal_point (See my mail at php-general). Now I took a quick look in the source code and I found this in ext/standard/string.c (function setlocale): if (cat == LC_NUMERIC || cat == LC_ALL) { struct lconv lc; localeconv_r(&lc); EG(float_separator)[0] = (lc.decimal_point)[0]; if ((lc.decimal_point)[0] != '.') { /* set locale back to C */ setlocale(LC_NUMERIC, "C"); } } I think this explains the misbehaviour. If I do a "setlocale(LC_ALL, 'de_DE')" then the PHP function resets LC_NUMERIC to "C". So what chance have I to get the LC_NUMERIC configuration of a specific locale now? Well, I think there was a good reason to reset LC_NUMERIC to C but this breaks localeconv(). I want to read the LC_NUMERIC configuration of the selected locale to use these informations with the number_format() function but I can't do it because of the above code. Is there a workaround? If not, then I suggest one (or both) of the following improvements: 1. setlocale remembers the real LC_NUMERIC setting before reseting it to C and localeconv sets this remembered locale before calling the localeconv_r() function. After the data has been retrieved, it resets LC_NUMERIC to C. in that way localeconv() behaves correctly and PHP still sticks to the default LC_NUMERIC setting. 2. You give localeconv optional parameters (same as setlocale) so it can be used to retrieve the locale configuration of a specific locale WITHOUT changing the global locale at all.
-- Bye, K <http://www.ailis.de/~k/> (FidoNet: 2:240/2188.18) [A735 47EC D87B 1F15 C1E9 53D3 AA03 6173 A723 E391] (Finger k@ailis.de to get public key)

Moriyoshi Koizumi

21 years ago
On 2004/10/30, at 21:43, Klaus Reimer wrote:
> > I think this explains the misbehaviour. If I do a "setlocale(LC_ALL, > 'de_DE')" then the PHP function resets LC_NUMERIC to "C". So what > chance have I to get the LC_NUMERIC configuration of a specific locale > now? Well, I think there was a good reason to reset LC_NUMERIC to C > but this breaks localeconv(). I want to read the LC_NUMERIC > configuration of the selected locale to use these informations with > the number_format() function but I can't do it because of the above > code. Is there a workaround?
Yup, save all the relevant environment variables beforehand and restore them with setlocale() after the localeconv() call. Either way, That's a valid bug that needs attention. Moriyoshi

Klaus Reimer

21 years ago
Moriyoshi Koizumi wrote:
> Yup, save all the relevant environment variables beforehand and > restore them with setlocale() after the localeconv() call. > Either way, That's a valid bug that needs attention.
It's already in the BTS (#30638) and is already assigned.
-- Bye, K <http://www.ailis.de/~k/> (FidoNet: 2:240/2188.18) [A735 47EC D87B 1F15 C1E9 53D3 AA03 6173 A723 E391] (Finger k@ailis.de to get public key)

Derick Rethans

21 years ago
On Wed, 3 Nov 2004, Moriyoshi Koizumi wrote:
> On 2004/10/30, at 21:43, Klaus Reimer wrote: > > > > > I think this explains the misbehaviour. If I do a "setlocale(LC_ALL, > > 'de_DE')" then the PHP function resets LC_NUMERIC to "C". So what > > chance have I to get the LC_NUMERIC configuration of a specific locale > > now? Well, I think there was a good reason to reset LC_NUMERIC to C > > but this breaks localeconv(). I want to read the LC_NUMERIC > > configuration of the selected locale to use these informations with > > the number_format() function but I can't do it because of the above > > code. Is there a workaround? > > Yup, save all the relevant environment variables beforehand and > restore them with setlocale() after the localeconv() call. > Either way, That's a valid bug that needs attention.
It's assigned to me for now... I'll have a look at it this week. Does somebody remember why we need to mangle the locale anyway by resetting LC_NUMERIC to "C"? Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Moriyoshi Koizumi

21 years ago
On 2004/11/03, at 17:11, Derick Rethans wrote:
> It's assigned to me for now... I'll have a look at it this week. Does > somebody remember why we need to mangle the locale anyway by resetting > LC_NUMERIC to "C"?
Good to hear the problem is then going to be addressed. According to the annotation, the change (1.320) was made by Ilia with the following comment: This patch fixes handling of floats on locales where decimal point is not a '.'. Problem is best demonstrated by bug #17079. ( http://cvs.php.net/co.php/php-src/ext/standard/string.c?r=1.320 ) I suppose the root of the problem is that the engine relies on strtod() that is affected by the locale settings. IIRC, there are some threads regarding this... I can't name one though. Moriyoshi

Derick Rethans

21 years ago
On Wed, 3 Nov 2004, Moriyoshi Koizumi wrote:
> I suppose the root of the problem is that the engine relies on > strtod() that is affected by the locale settings. IIRC, > there are some threads regarding this... I can't name one though.
I think a much better solution would be to use our own "strtod" function that isn't affected by locales then. I guess we could borrow a BSD implementatino of it and modify this to our needs. Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Moriyoshi Koizumi

21 years ago
On 2004/11/03, at 18:57, Derick Rethans wrote:
> I think a much better solution would be to use our own "strtod" > function > that isn't affected by locales then. I guess we could borrow a BSD > implementatino of it and modify this to our needs.
My +1 if some vote will take place. See also: http://marc.theaimsgroup.com/?l=php-dev&m=102448633702445&w=2 Moriyoshi

Hartmut Holzgraefe

21 years ago
Derick Rethans wrote:
> On Wed, 3 Nov 2004, Moriyoshi Koizumi wrote: > >>I suppose the root of the problem is that the engine relies on >>strtod() that is affected by the locale settings. IIRC, >>there are some threads regarding this... I can't name one though. > > I think a much better solution would be to use our own "strtod" function > that isn't affected by locales then. I guess we could borrow a BSD > implementatino of it and modify this to our needs.
so there are still locale dependant functions within the Engine? :(((( I thought we had finally eliminated these ...
-- Hartmut Holzgraefe <hartmut@php.net>

Derick Rethans

21 years ago
On Wed, 3 Nov 2004, Hartmut Holzgraefe wrote:
> Derick Rethans wrote: > > On Wed, 3 Nov 2004, Moriyoshi Koizumi wrote: > > > >>I suppose the root of the problem is that the engine relies on > >>strtod() that is affected by the locale settings. IIRC, > >>there are some threads regarding this... I can't name one though. > > > > I think a much better solution would be to use our own "strtod" function > > that isn't affected by locales then. I guess we could borrow a BSD > > implementatino of it and modify this to our needs. > > so there are still locale dependant functions within the Engine? :(((( > > I thought we had finally eliminated these ...
They were fixed, but broke output of localeconv(). Now this should be fixed too, and fixed for good! regards, Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org