Bug #77347 [Dup]: switch casting behavior by setlocale(LC_NUMERIC, '') is wrong

Edit report at https://bugs.php.net/bug.php?id=77347&edit=1 ID: 77347 Updated by: cmb@php.net Reported by: spam2 at rhsoft dot net Summary: switch casting behavior by setlocale(LC_NUMERIC, '') is wrong Status: Duplicate Type: Bug Package: Scripting Engine problem Operating System: Linux PHP Version: 7.2.13 Assigned To: cmb Block user comment: N Private report: N New Comment: > if it don't touch it how can it be C then when the environment > is DE This is defined by POSIX[1]: | The POSIX locale is the default global locale at entry to | main(). (The C locale is equivalent to the POSIX locale.) POSIX futher elaborates: | Internationalized programs can initiate language operation | according to environment variable settings […] Note the word “can”. [1] <http://pubs.opengroup.org/onlinepubs/9699919799/functions/setlocale.html> Previous Comments: ------------------------------------------------------------------------ [2018-12-26 17:53:59] spam2 at rhsoft dot net http://git.php.net/?p=php-src.git;a=commit;h=7e0baa7a1daa531e39881e59842c88d12e42c901 and "Revert Thies' locale patch. It was screwing up language level things" 18 years ago should not have reverted but the "language level things" fixed so that they are *not* get screwed up just because setlocale() exists somewhere left and right in the code ------------------------------------------------------------------------ [2018-12-26 17:36:09] spam2 at rhsoft dot net if it don't touch it how can it be C then when the environment is DE ------------------------------------------------------------------------ [2018-12-26 17:18:15] cmb@php.net > can you explain me why for php LC_NUMERIC is set to C while the > locale of the session is german other then to prevent that sort of > confusion until somebody is touching locale after script start? PHP's core does not touch any locale settings (so all default to C), except for LC_TYPE[1]. > if php would act here consistent I pretty sure would never have > written that casting code to begin with […] See commit 7e0baa7[2] why initializing LC_ALL might not be the best idea. [1] <https://github.com/php/php-src/blob/9882929bfa4422765c1b1fde6a612fa48bfcce2e/main/main.c#L2180> [2] <http://git.php.net/?p=php-src.git;a=commit;h=7e0baa7a1daa531e39881e59842c88d12e42c901> ------------------------------------------------------------------------ [2018-12-26 15:46:10] spam2 at rhsoft dot net well, comments for the other Bugreport are disabled can you explain me why for php LC_NUMERIC is set to C while the locale of the session is german other then to prevent that sort of confusion until somebody is touching locale after script start? if php would act here consistent I pretty sure would never have written that casting code to begin with because this dumb behavior would have jumped straight in my face all the time and not just by a random library which touched locale the float-to-string locale behavior is plain wrong and not that the other direction don't convert back correctly if one is interest in locale format he is using a format function and not type casting ------------------------------------------------------------------------ [2018-12-26 15:28:07] cmb@php.net What are you trying to convey here? The fact that setlocale(LC_NUMERIC, '') changes the locale setting according to the environment is well documented[1], and that the decimal separator is locale depending for float to string casts[2]. Other than that, I can't see how this bug report isn't a duplicate of bug #77278, where it already has been explained in detail that: | 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. To additionally clarify the word “simple” above: of course it is simple to change the behavior, but that would likely cause a massive BC break, so we cannot do this for the next minor version, or even a revision, but would have at least to wait for the next major PHP version. And yes, somebody would need to take the time to walk through the RFC process[3]. [1] <http://php.net/manual/en/function.setlocale.php> [2] <http://php.net/manual/en/language.types.string.php#language.types.string.casting> [3] <https://wiki.php.net/rfc/howto> ------------------------------------------------------------------------ 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=77347 -- Edit this bug report at https://bugs.php.net/bug.php?id=77347&edit=1