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:
-
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 waylocaleconv()
behaves correctly and PHP
still sticks to the defaultLC_NUMERIC
setting. -
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)
I think this explains the misbehaviour. If I do a "setlocale(LC_ALL,
'de_DE')" then the PHP function resetsLC_NUMERIC
to "C". So what
chance have I to get theLC_NUMERIC
configuration of a specific locale
now? Well, I think there was a good reason to resetLC_NUMERIC
to C
but this breakslocaleconv()
. I want to read theLC_NUMERIC
configuration of the selected locale to use these informations with
thenumber_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
Moriyoshi Koizumi wrote:
Yup, save all the relevant environment variables beforehand and
restore them withsetlocale()
after thelocaleconv()
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)
I think this explains the misbehaviour. If I do a "setlocale(LC_ALL,
'de_DE')" then the PHP function resetsLC_NUMERIC
to "C". So what
chance have I to get theLC_NUMERIC
configuration of a specific locale
now? Well, I think there was a good reason to resetLC_NUMERIC
to C
but this breakslocaleconv()
. I want to read theLC_NUMERIC
configuration of the selected locale to use these informations with
thenumber_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 withsetlocale()
after thelocaleconv()
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
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
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
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
Derick Rethans 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 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