Inconsistent float to string vs. string to float casting

On Wed, Dec 26, 2018 at 4:48 PM Christoph M. Becker <cmbecker69@gmx.de> wrote:

Yes, please. Locale-sensitive library functions are bad enough, but core language behavior should *never* be locale-sensitive. I'm definitely in favor of making float to string casts locale-independent in PHP 8. Nikita

cmbecker69@gmx.de ("Christoph M. Becker") wrote:

I'm shocked... Lot of code here assumes (float) does the exact reverse of (string); forunately most servers are configures with the default locale "C", but I'm still concerned for libraries portability. Did you filed a bug for that? Anyway, here is some test code I wrote: <?php // test-float-cast.php /** * Performs string to float and float to string tests vs. locale. * @param string $loc LC_NUMERIC locale to set for the test. */ function test($loc) { if( setlocale(LC_NUMERIC, $loc) === FALSE ) throw new RuntimeException("setlocale() failed"); // Cast float to string test: $exp = "0.5"; $got = (string) 0.5; if( $got !== $exp ) echo "FAILED with LC_NUMERIC=$loc, (string) 0.5: got $got, exp $exp\n"; // Cast string to float test: $exp = 0.5; $got = (float) "0.5"; if( $got !== $exp ) echo "FAILED with LC_NUMERIC=$loc, (float) \"0.5\": got $got, exp $exp\n"; // printf() formatting of float: $exp = "0.500000"; $got = sprintf("%f", 0.5); if( $got !== $exp ) echo "FAILED with LC_NUMERIC=$loc, sprintf(\"%f\", 0.5): got $got, exp $exp\n"; } test("C"); test("de"); Output: FAILED with LC_NUMERIC=de, (string) 0.5: got 0,5, exp 0.5 FAILED with LC_NUMERIC=de, sprintf("%f", 0.5): got 0,500000, exp 0.500000 The second failed test is expected, as printf, scanf and co. are intended to be locale-aware. But the first one? Is there any simple, efficient and safe way to convert back a string into float? Regards, ___ /_|_\ Umberto Salsi \/_\/ www.icosaedro.it

Hi!

That may be inconvenient, but changing it now would be way worse IMHO. Ideally, system conversions would return well-defined result (locale as a global is a *horrible* idea which can only be explained by it's genesis in simpler times where most of the software was written to be run in one specific environment and user putting a pack of punch cards into the reader would only need them to be processed in one locale) and for configurable outcome you'd use functions that receive explicit parameters.

If you mean that loading "0.3" from string would suddenly stop working in Germany, then never. If you mean that (string)0.3 would return "0.3" and not "0,3" in Germany, then again I'd say probably never, though very slightly less confidently. Those people who didn't want it already have code to deal with it, and those that wanted it would have their unit tests crash and burn and their data pipelines blow up. I think it's a very bad idea to change such things, which would create hundreds of year-persons of headache to anybody daring to upgrade. I understand it's a bad situation, but I think the right exit of it is to tell people that want predictable roundtrip results to use specific number conversion functions, and not exchange one mess to another, BC-breaking and havoc-wreaking, mess. I agree that the right thing to do would be to have (string)0.3 to always use dot and never use locale (did I mention I think global locale is a horrible idea?) but that ship has sailed. I don't see a use case that would be well served by breaking the BC now.

cmbecker69@gmx.de ("Christoph M. Becker") wrote:

We all agree that the basic features of the language should NOT be locale-aware to make easier error reporting and logging, data file writing and parsing, session management, and libraries portability. But I would to restate this goal more clearly: FLOAT TO STRING CAST CONVERSION REPLACEMENT Given a floating-point value, retrieve its canonical PHP source-code string representation. By "canonical" I mean something that can be parsed by the PHP interpreter like a floating-point number, not like an int or anything else. Then, for example, 123.0 must be rendered as "123.0" not as "123" because it looks like an int; non-finite values NAN and INF must also be rendered as "NAN" and "INF". The "(string)" cast and the embedded variable in string "$f" are locale-aware, and so are all the printf() &Co. functions, including var_dump() (this latter a big surprise; anyone willing to send a data structure dump to end user?). The simplest way I found to get such canonical representation is $s = var_export($f, TRUE); which returns exactly what I expect, does not depend on the current locale, does not depend on exotic libraries, and it is very short and simple. It depends only on the current serialize_precision php.ini parameter, which should already be set right (or you are going to have problems elsewhere). STRING TO FLOAT CAST CONVERSION REPLACEMENT Given a string carrying the canonical representation of a floating-point number, retrieve the floating-point number. Syntax errors must be detectable. The result must be "float", not int or anything else. Unsure about how much strict the parser should be in these edge cases: "+1.2" (redundant plus sign) "123" (looks like int, not a float) "0123" (looks like int octal base) Getting all this is bit more tricky. The "(float)" cast does not work because it does not support non-finite values NAN,INF and does not allow to detect errors. The simplest way I found is by using the serialize() function: /** * Parses the PHP canonical representation of a floating point number. This * function parses any valid PHP source code representation of a "float", * including NAN, INF, -INF and -0 (IEEE 754 zero negative). Not locale aware. * @param string $s String to parse. No spaces allowed, apply trim() if needed. * @return float Parsed floating-point number. * @throws InvalidArgumentException Invalid syntax. */ function parseFloat($s) { // Security: untrusted strings must be checked against a basic syntax before // being blindly submitted to unserialize(): if( preg_match("/^[-+]?(NAN|INF|[-+.0-9eE]++)\$/sD", $s) !== 1 ) throw new InvalidArgumentException("cannot parse as a floating point number: '$s'"); // unserialize() raises an E_NOTICE on parse error and then returns FALSE. $m = @unserialize("d:$s;"); if( is_int($m) ) return (float) $m; // always return what we promised if( is_float($m) ) return $m; throw new InvalidArgumentException("cannot parse as a floating point number: '$s'"); } Here again, only core libraries involved, no dependencies from the locale, not so short but the best I found up now. Things like NumberFormatter require the 'intl' extension be enabled, and often it isn't. By using these functions all the possible "float" values pass the round-trip back and forth, including NAN, INF, -INF, -0 (zero negative, for what it worth) at the highest accuracy possible of the IEEE 754 representation. Regards, ___ /_|_\ Umberto Salsi \/_\/ www.icosaedro.it

On 26.12.2018 at 16:47, Christoph M. Becker wrote:

Well, there's a special case, though: $string = (1/3) . 'foo'; // string(19) "0.33333333333333foo" This is caused by a compile-time optimization, which obviously occurs before any locale *can* be set.