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] hholzgra@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] hholzgra@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] cataphract@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