Re: Re: locale bug from php4.3.0

Zitat von Jan Schneider <jan@horde.org>: > Giuseppe Tanzilli - Csf wrote: > > Hi, > > just porting big 4.2.3 application to 4.3.2rc, > > I see something changed from 4.3.0 about locale settings. > > > > Before 4.3.0 locale was used to print out numbers in string format > > and to read numbers from string formats. > > I mean php uses the decimal delimiter definied in the locale settings. > > > > From 4.3.0 on, php uses the decimal delimiter from locale only to > > output numbers to strings, > > not when read numbers from strings. > > > > Why ? > > > > Every other language works the old pre 4.3.0 way. > > > > This way every serious application needs alot of work to run on php > > >=4.3.0!!!! > > > > Please explain why this change was made. > > > > I saw in setlocale source in ext/standard/strings.c, > > if ((lc.decimal_point)[0] != '.') { > > /* set locale back to C */ > > setlocale(LC_NUMERIC, "C"); > > } > > this sets LC_NUMERIC to C in every case > > > > I'm in Italy and here we use comma as decimal delimiter. > > It looks like noone answered to this message yet, but I have to agree > that this is a serious issue. Not only is it breaking backward > compatibility, it now isn't even possible anymore to get numeric locale > information if the selected locale contains a "," as the decimal > separator. > > I understand why PHP doesn't want to behave like other programming > languages because it is weak typed and people expect (float)"1.5" to be > always 1.5 - independent from the current locale. > > But the fix is completely wrong. This has to fixed in the casting code > not by resetting LC_NUMERIC if the decimal separator is a ",". Not only > isn't it documented anywhere, I found it out while tracking a bug in > Horde after I've taken a closer look at string.c (I didn't believe my > eyes!) It also breaks everything else depending on the current > LC_NUMERIC locale, like localeconv() or not foreseeable calls to > external libraries or programs. > > This is PHP problem, so it has to be fixed in PHP not by changing its > environment! > > I hope this will be fixed soonish as currently it's impossible to parse > user input depending on his locale settings. I know, i18n is (unfortunately) not one of the top priorities of current development, but this one is really a huge issue and a simply wrong fix for it. It would be great if at least someone could comment on it whether it won't be fixed soon or not all or give some reasons why this won't be fixed. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft