# localeconv not working
- Thread: https://externals.io/message/13632
- Original archive: https://news-web.php.net/php.internals/13632
- Started by Klaus Reimer on 2004-10-30T12:43:18+00:00
- Messages: 9
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt
---
## #13632 — Klaus Reimer — 2004-10-30T12:43:18+00:00
URL: https://externals.io/message/13632#13632
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 (FidoNet: 2:240/2188.18)
[A735 47EC D87B 1F15 C1E9 53D3 AA03 6173 A723 E391]
(Finger k@ailis.de to get public key)
---
## #13697 — Moriyoshi Koizumi — 2004-11-03T07:04:09+00:00
URL: https://externals.io/message/13632#13697 · In reply to: #13632
>
> 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
---
## #13698 — Klaus Reimer — 2004-11-03T07:12:55+00:00
URL: https://externals.io/message/13632#13698 · In reply to: #13697
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 (FidoNet: 2:240/2188.18)
[A735 47EC D87B 1F15 C1E9 53D3 AA03 6173 A723 E391]
(Finger k@ailis.de to get public key)
---
## #13701 — Derick Rethans — 2004-11-03T08:11:08+00:00
URL: https://externals.io/message/13632#13701 · In reply to: #13697
>
>
> > […]
>
> 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
---
## #13702 — Moriyoshi Koizumi — 2004-11-03T09:33:59+00:00
URL: https://externals.io/message/13632#13702 · In reply to: #13701
> 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
---
## #13703 — Derick Rethans — 2004-11-03T09:57:49+00:00
URL: https://externals.io/message/13632#13703 · In reply to: #13702
> 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
---
## #13704 — Moriyoshi Koizumi — 2004-11-03T10:17:15+00:00
URL: https://externals.io/message/13632#13704 · In reply to: #13703
> 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
---
## #13720 — Hartmut Holzgraefe — 2004-11-03T22:33:15+00:00
URL: https://externals.io/message/13632#13720 · In reply to: #13703
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.
so there are still locale dependant functions within the Engine? :((((
I thought we had finally eliminated these ...
--
Hartmut Holzgraefe Derick Rethans wrote:
> > […]
>
> 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