Edit report at https://bugs.php.net/bug.php?id=54547&edit=1
ID: 54547 Comment by: nik at naturalnet dot de Reported by: peter dot ritt at gmx dot net Summary: wrong equality of string numbers Status: Verified Type: Bug Package: Unknown/Other Function Operating System: linux PHP Version: 5.3.6 Assigned To: dmitry Block user comment: N Private report: N New Comment: *Why* the heck is that implicit cast even done? Are PHP developers really _that_ absent-minded that they cannot write actual number literals when they want them (i.e. leave out the '')? I expect any programming language to use the data types I give it, not something it likes more! Previous Comments: ------------------------------------------------------------------------ [2012-04-11 10:52:06] hholz...@php.net On "0xFF" == 255: since when do we actually consider hex in strings as numeric? And is this actually documented? The The "String conversion to numbers" section in the manual says: "Valid numeric data is an optional sign, followed by one or more digits (optionally containing a decimal point), followed by an optional exponent. The exponent is an 'e' or 'E' followed by one or more digits." ( http://www.php.net/manual/en/language.types.string.php#language.types.string.conversion ) By that description 0xsomething would *not* be considered as numeric in a string context ... ------------------------------------------------------------------------ [2012-04-11 10:45:46] hholz...@php.net If we indeed want to change the behavior here (and i'm yet undecided to whether i'd want to do this or not, although slightly biased towards a 'yes): wouldn't it be easier (although probably slightly less effective performance wise) to do a string comparison first if both arguments are strings, and only fall back to numeric auto casts if the string comparison fails? If the strings really contain different numeric literals i'd expect a string comparison to fail quickly as there can only be so much digits (ok, in theory you could have up to 300+ digits, but not all of them significant). This would take care of all possible edge cases (assuming that there may be others that we aren't aware of yet, even though i can't think of any right now) and not just the overflow case at hand, and the required engine changes would probably be a single chunk only, so having better patch locality ... Or are there other places where we'd need an extended is_numeric_string check with overflow control, too? ------------------------------------------------------------------------ [2012-04-11 08:44:39] net at janoszen dot hu Same problem: php > var_dump('0xff' == '255'); bool(true) ------------------------------------------------------------------------ [2012-04-11 07:47:21] foobla at spambog dot com I don't think it's about PHP_MAX_INT, rather about the maximum precision of a double/float. "==" converts both strings to numbers (after spending CPU cycles to detect whether they look like numbers), as described in http://www.phpsadness.com/sad/47 once converted, the floats seem to actually *be* equal, even with "===": php -r ' $a = (double)"9223372036854775807"; $b = (double)"9223372036854775808"; var_dump($a, $b, $a == $b, $a === $b); ' float(9.2233720368548E+18) float(9.2233720368548E+18) bool(true) bool(true) ------------------------------------------------------------------------ [2011-04-18 03:04:14] cataphr...@php.net Maybe this should be Won't Fix to keep it consistent with 9223372036854775807 == 9223372036854775808 (with number literals). ------------------------------------------------------------------------ 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=54547 -- Edit this bug report at https://bugs.php.net/bug.php?id=54547&edit=1
