Bug #54547 [Ver]: wrong equality of string numbers
Edit report at https://bugs.php.net/bug.php?id=54547edit=1 ID: 54547 Updated by: paj...@php.net 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: @a at hotmail dot com This is not a support channel, if you need further support for the base ideas about the loosely type nature of PHP, please ask them on one the numerous channels. Previous Comments: [2012-04-12 06:39:30] paj...@php.net @a at hotmail dot com This is not a support channel, if you need further support for the base ideas about the loosely type nature of PHP, please ask them on one the numerous channels. [2012-04-12 06:39:30] paj...@php.net @a at hotmail dot com This is not a support channel, if you need further support for the base ideas about the loosely type nature of PHP, please ask them on one the numerous channels. [2012-04-12 05:42:53] a at hotmail dot com @paj...@php.net How about *you* staying polite with your users by actually fixing your bugs? Can you imagine how much time is wasted worldwide as a consequence of your shortsighted design decisions? [2012-04-11 13:36:46] paj...@php.net @nik at naturalnet dot de Please stay polite with other developers. Please keep in mind that PHP is loosely typed, this is a root principle of PHP. [2012-04-11 13:12:14] nik at naturalnet dot de *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! 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=54547edit=1
Bug #54547 [Ver]: wrong equality of string numbers
Edit report at https://bugs.php.net/bug.php?id=54547edit=1 ID: 54547 Updated by: paj...@php.net 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: @a at hotmail dot com This is not a support channel, if you need further support for the base ideas about the loosely type nature of PHP, please ask them on one the numerous channels. Previous Comments: [2012-04-12 05:42:53] a at hotmail dot com @paj...@php.net How about *you* staying polite with your users by actually fixing your bugs? Can you imagine how much time is wasted worldwide as a consequence of your shortsighted design decisions? [2012-04-11 13:36:46] paj...@php.net @nik at naturalnet dot de Please stay polite with other developers. Please keep in mind that PHP is loosely typed, this is a root principle of PHP. [2012-04-11 13:12:14] nik at naturalnet dot de *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! [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? 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=54547edit=1
Bug #54547 [Ver]: wrong equality of string numbers
Edit report at https://bugs.php.net/bug.php?id=54547edit=1 ID: 54547 Updated by: paj...@php.net 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: @a at hotmail dot com This is not a support channel, if you need further support for the base ideas about the loosely type nature of PHP, please ask them on one the numerous channels. Previous Comments: [2012-04-12 06:39:30] paj...@php.net @a at hotmail dot com This is not a support channel, if you need further support for the base ideas about the loosely type nature of PHP, please ask them on one the numerous channels. [2012-04-12 05:42:53] a at hotmail dot com @paj...@php.net How about *you* staying polite with your users by actually fixing your bugs? Can you imagine how much time is wasted worldwide as a consequence of your shortsighted design decisions? [2012-04-11 13:36:46] paj...@php.net @nik at naturalnet dot de Please stay polite with other developers. Please keep in mind that PHP is loosely typed, this is a root principle of PHP. [2012-04-11 13:12:14] nik at naturalnet dot de *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! [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 ... 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=54547edit=1
Bug #54547 [Ver]: wrong equality of string numbers
Edit report at https://bugs.php.net/bug.php?id=54547edit=1 ID: 54547 Updated by: paj...@php.net 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: @Jeff at bobmail dot info that's what === is for (real comparisons without casting). Previous Comments: [2012-04-12 13:51:22] jabakobob at gmail dot com The conversion to a number is necessary because programmers don't differentiate between strings and numbers in PHP. Consider the following code: if ($_GET[a] == $_GET[b]) echo a is same as b!; The result will be the same if the query string is ?a=1b=1 or ?a=1b=1.0 or ? a=01b=1 because PHP is loosely typed. Internally $_GET[a] and $_GET[b] are both strings, but we can't do a string comparison. If you want a string comparison, use strcmp. [2012-04-12 13:31:42] Jeff at bobmail dot info I'm confused as to why there is even a conversation around should we fix this. The data objects are strings. Sure, PHP is loosely typed but shouldn't it do the comparison you tell it to do first before attempting anything else? I agree with the previous suggestion: make it a real string comparison and drop the type casting. [2012-04-12 06:39:31] paj...@php.net @a at hotmail dot com This is not a support channel, if you need further support for the base ideas about the loosely type nature of PHP, please ask them on one the numerous channels. [2012-04-12 06:39:30] paj...@php.net @a at hotmail dot com This is not a support channel, if you need further support for the base ideas about the loosely type nature of PHP, please ask them on one the numerous channels. [2012-04-12 06:39:30] paj...@php.net @a at hotmail dot com This is not a support channel, if you need further support for the base ideas about the loosely type nature of PHP, please ask them on one the numerous channels. 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=54547edit=1
Bug #54547 [Ver]: wrong equality of string numbers
Edit report at https://bugs.php.net/bug.php?id=54547edit=1
ID: 54547
Updated by: jpa...@php.net
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:
I'd like to add that strcmp() and familly are functions designed to compare
strings, as they are in C ; except that in PHP they are binary compatible, like
PHP strings are
Previous Comments:
[2012-04-12 14:17:32] ni...@php.net
@Jeff Please see jabakobob's comment why doing just a string comparison can be
counterproductive. Remember: PHP is mainly used around the HTTP protocol (where
everything is a string) and MySQL (where also everything is returned as a
string). So in PHP you will often deal with numbers in strings, thus they
should be handled as such.
[2012-04-12 14:02:02] Jeff at bobmail dot info
That didn't address my comment. Why wouldn't the internal implementation check
to see if the strings are the same? When doing a comparison and the internal
data type is a string, wouldn't that be faster and most correct?
In all honesty I would prefer PHP's loosely typed system mimic JavaScript's
in that any type can be put anywhere but the object still keeps its type
information for situations just like this.
[2012-04-12 13:59:32] ni...@php.net
@Jeff: You have to understand in PHP 1, 1.0 and 1.0 all are equivalent (in
most situations). That's by design.
E.g. GET and POST variables are always strings, even if you put numbers into
them (as per the HTTP standard). PHP obviously wants those GET/POST variables
to still be useable just like they were numbers, that's why 1 and 1 can be
used interchangeably throughout PHP.
In that context - in my eyes - this comparison also makes sense. Consider a
very similar comparison:
var_dump('0.1' == '0.1000');
What would you expect to be the output - if you remember that in PHP numeric
strings and actual numbers are interchangeable? Clearly it has to behave
exactly as if you had written:
var_dump(0.1 == 0.1000); // = bool(true)
In most cases this type of comparison is what you want and it usually works
exactly as expected.
What you see here in this issue is one of the edge cases (how often do you use
large numbers in PHP?) where it does not work well.
I hope you understand that it is not viable to remove a handy feature from PHP,
just because it fails under certain edge case conditions.
If you want to use a strict string comparison, just use ===.
[2012-04-12 13:58:53] paj...@php.net
@Jeff at bobmail dot info
that's what === is for (real comparisons without casting).
[2012-04-12 13:51:22] jabakobob at gmail dot com
The conversion to a number is necessary because programmers don't differentiate
between strings and numbers in PHP. Consider the following code:
if ($_GET[a] == $_GET[b]) echo a is same as b!;
The result will be the same if the query string is ?a=1b=1 or ?a=1b=1.0 or ?
a=01b=1 because PHP is loosely typed.
Internally $_GET[a] and $_GET[b] are both strings, but we can't do a string
comparison. If you want a string comparison, use strcmp.
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=54547edit=1
Bug #54547 [Ver]: wrong equality of string numbers
Edit report at https://bugs.php.net/bug.php?id=54547edit=1
ID: 54547
Updated by: ras...@php.net
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:
@jacob PHP has two sets of comparison operators as well. == and ===
They aren't numeric and string, they are loose and strict. In the majority of
cases when dealing with HTTP requests and database results, which is what PHP
deals with most, the loose comparison makes life easiest on the developer.
In your case when comparison huge numeric strings that won't fit in any numeric
type, a strict comparison is needed:
$ php -r 'var_dump(61529519452809720693702583126814 ===
6152951945280972);'
bool(false)
(and hopefully you aren't actually using md5 for password hashing)
Previous Comments:
[2012-04-12 16:04:03] jacob at fakku dot net
I'm just gonna paste in that PHP Sadness article to show why this is such a big
issue.
According to php language.operators.comparison, the type-coercing comparison
operators will coerce both operands to floats if they both look like numbers,
even if they are both already strings:
If you compare a number with a string or the comparison involves numerical
strings, then each string is converted to a number and the comparison performed
numerically.
This can become especially important in situations where the developer chooses
to use == to compare two values which will always be strings. For example,
consider a simple password checker:
if (md5($password) == $hash) {
print Allowed!\n;
}
Assume that the $hash is loaded from a known safe string value from a database
and contains a real MD5 hash. Now, suppose the $password is ximaz, which has
an all-numeric hex-encoded MD5 hash of 61529519452809720693702583126814. When
PHP does the comparison, it will print Allowed! for any password which
matches
even the first half of the hash:
$ php -r 'var_dump(61529519452809720693702583126814 ==
6152951945280972);'
bool(true)
The solution, of course, is never use type-coercing comparison operators -
but
this remains an easily-overlooked bug factory for beginning and even
intermediate developers. Some languages solve this situation by having two
separate sets of comparison operators for numeric or string comparisons so that
the developer can be explicit in their intent without needing to manually cast
their arguments.
[2012-04-12 15:55:26] yless42 at hotmail dot com
Wouldn't it make the most sense to compare the strings as string (and thus pass
in the original case), then fall back on other comparison methods when they
don't match? I admit I don't have test cases but it seems that this would be
backwards compatible in most cases (as you will eventually compare numerically)
and fix the given issue.
Unless there are cases which rely on the two same strings failing to compare as
equal.
[2012-04-12 15:20:45] jpa...@php.net
I'd like to add that strcmp() and familly are functions designed to compare
strings, as they are in C ; except that in PHP they are binary compatible, like
PHP strings are
[2012-04-12 14:17:32] ni...@php.net
@Jeff Please see jabakobob's comment why doing just a string comparison can be
counterproductive. Remember: PHP is mainly used around the HTTP protocol (where
everything is a string) and MySQL (where also everything is returned as a
string). So in PHP you will often deal with numbers in strings, thus they
should be handled as such.
[2012-04-12 14:02:02] Jeff at bobmail dot info
That didn't address my comment. Why wouldn't the internal implementation check
to see if the strings are the same? When doing a comparison and the internal
data type is a string, wouldn't that be faster and most correct?
In all honesty I would prefer PHP's loosely typed system mimic JavaScript's
in that any type can be put anywhere but the object still keeps its type
information for situations just like this.
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=54547edit=1
Bug #54547 [Ver]: wrong equality of string numbers
Edit report at https://bugs.php.net/bug.php?id=54547edit=1
ID: 54547
Updated by: hholz...@php.net
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:
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?
Previous Comments:
[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).
[2011-04-17 05:44:03] cataphr...@php.net
The following patch has been added/updated:
Patch Name: bug54547-2.diff
Revision: 1303011843
URL:
http://bugs.php.net/patch-display.php?bug=54547patch=bug54547-2.diffrevision=1303011843
[2011-04-17 01:59:59] cataphr...@php.net
The following patch has been added/updated:
Patch Name: bug54547.diff
Revision: 1302998399
URL:
http://bugs.php.net/patch-display.php?bug=54547patch=bug54547.diffrevision=1302998399
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=54547edit=1
Bug #54547 [Ver]: wrong equality of string numbers
Edit report at https://bugs.php.net/bug.php?id=54547edit=1
ID: 54547
Updated by: hholz...@php.net
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:
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 ...
Previous Comments:
[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).
[2011-04-17 05:44:03] cataphr...@php.net
The following patch has been added/updated:
Patch Name: bug54547-2.diff
Revision: 1303011843
URL:
http://bugs.php.net/patch-display.php?bug=54547patch=bug54547-2.diffrevision=1303011843
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=54547edit=1
Bug #54547 [Ver]: wrong equality of string numbers
Edit report at https://bugs.php.net/bug.php?id=54547edit=1
ID: 54547
Updated by: paj...@php.net
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:
@nik at naturalnet dot de
Please stay polite with other developers.
Please keep in mind that PHP is loosely typed, this is a root principle of PHP.
Previous Comments:
[2012-04-11 13:12:14] nik at naturalnet dot de
*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!
[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)
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=54547edit=1
Bug #54547 [Ver]: wrong equality of string numbers
Edit report at http://bugs.php.net/bug.php?id=54547edit=1
ID: 54547
Updated by: cataphr...@php.net
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:
Maybe this should be Won't Fix to keep it consistent with
9223372036854775807 == 9223372036854775808 (with number literals).
Previous Comments:
[2011-04-17 05:44:03] cataphr...@php.net
The following patch has been added/updated:
Patch Name: bug54547-2.diff
Revision: 1303011843
URL:
http://bugs.php.net/patch-display.php?bug=54547patch=bug54547-2.diffrevision=1303011843
[2011-04-17 01:59:59] cataphr...@php.net
The following patch has been added/updated:
Patch Name: bug54547.diff
Revision: 1302998399
URL:
http://bugs.php.net/patch-display.php?bug=54547patch=bug54547.diffrevision=1302998399
[2011-04-16 20:07:43] peter dot ritt at gmx dot net
Description:
comparison of strings using == shows wrong results when both strings are
numbers (digits) around PHP_MAX_INT;
the same comparison using === works correctly;
tested on 64 bit systems only, affects also PHP 5.3.5
Test script:
---
$a = '9223372036854775807';
$b = '9223372036854775808';
if ($a == $b) {
echo $a == $b\n;
}
else {
echo $a != $b\n;
}
// displays 9223372036854775807 == 9223372036854775808
Expected result:
should display
9223372036854775807 != 9223372036854775808
Actual result:
--
displays
9223372036854775807 == 9223372036854775808
--
Edit this bug report at http://bugs.php.net/bug.php?id=54547edit=1
