Bug #77278 [Ver->Csd]: floatval(strval(value)) truncates if locale's decimal_point isn't a period

Edit report at https://bugs.php.net/bug.php?id=77278&edit=1 ID: 77278 Updated by: cmb@php.net Reported by: spam2 at rhsoft dot net Summary: floatval(strval(value)) truncates if locale's decimal_point isn't a period -Status: Verified +Status: Closed Type: Bug Package: Scripting Engine problem PHP Version: Irrelevant -Assigned To: +Assigned To: cmb Block user comment: Y Private report: N New Comment: This issue is resolved as of PHP 8.0.0[1]. [1] <https://wiki.php.net/rfc/locale_independent_float_to_string> Previous Comments: ------------------------------------------------------------------------ [2018-12-26 15:28:07] cmb@php.net Related To: Bug #77347 ------------------------------------------------------------------------ [2018-12-10 22:16:59] requinix@php.net spam2, there's two bugs here: 1. PHP converts by locale in one direction (float->string) but not in the other direction (string->float). It should be consistent. But like @nikic said, this inconsistency is currently the intended behavior - not the correct behavior, merely the *intended* behavior. It does need to get fixed but it's not a simple thing to just do. 2. Tidy changes locales for whatever reason. Okay. But it does not change the locale back to the original value when it is done, and that is not okay. It needs to change it back in case the calling code had set a locale and still needs it. That is just basic etiquette for any library code. This is a bug Tidy needs to fix, not PHP. Getting the locale is possible by passing null to setlocale. You probably aren't seeing en_US because you don't have the locale installed, and calling setlocale with it would have returned false. Do locale -a to see what you have available. ------------------------------------------------------------------------ [2018-12-10 21:59:50] nikic@php.net Please calm down. ------------------------------------------------------------------------ [2018-12-10 21:52:37] spam2 at rhsoft dot net ok, you can partially repdoduce that behavior echo (string)4/3, "\n"; setlocale(LC_ALL, 'en_US.UTF-8'); echo (string)4/3, "\n"; setlocale(LC_ALL, 'de_DE.UTF-8'); echo (string)4/3, "\n"; ------------------------------- BUT YOU CANN NOT GET THE CURRECT LOCALE WITH PHP echo (string)4/3, "\n"; setlocale(LC_ALL, 'en_US.UTF-8'); echo setlocale(LC_ALL, NULL), "\n"; echo (string)4/3, "\n"; setlocale(LC_ALL, 'de_DE.UTF-8'); echo setlocale(LC_ALL, NULL), "\n"; echo (string)4/3, "\n"; [harry@srv-rhsoft:/downloads]$ php test.php 1.3333333333333 de_DE.UTF-8 1,3333333333333 de_DE.UTF-8 1,3333333333333 ------------------------------- why don't that shit mention 'en_US.UTF-8' which i would have liked to put at the libtidy bugreport instead wasting all my time with assumptions? there is anyways no sibgle pojnt of have TYPECASTS behave different - that's what format functions are! ------------------------------------------------------------------------ [2018-12-10 21:45:13] spam2 at rhsoft dot net nonsense! show me the PHP code where type casts after setlocale() change tehir meaning! you can't even distinct what happens by use setlocale('whatever', NULL) before and after the tidy call because i get always get de_DE.UTF-8 as result ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=77278 -- Edit this bug report at https://bugs.php.net/bug.php?id=77278&edit=1