|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #9186 string compare with "==" does not work correctly
Submitted: 2001-02-09 03:25 UTC Modified: 2001-06-27 00:43 UTC
From: tom dot anheyer at berlinonline dot de Assigned:
Status: Closed Package: Documentation problem
PHP Version: 4.0.4pl1 OS: any
Private report: No CVE-ID: None
 [2001-02-09 03:25 UTC] tom dot anheyer at berlinonline dot de
First the test script:

$a = '012345678901234567';
$b = '012345678901234568';
echo ($a == $b) ? "a equal b\n" : "a not equal b\n";
echo ($a === $b) ? "a equal b\n" : "a not equal b\n";
printf ("as string: a=%s b=%s\n", $a, $b);
printf ("as float: a=%.0f b=%.0f\n", $a, $b);
printf ("as int: a=%d b=%d\n", $a, $b);

and its output:

a equal b
a not equal b
as string: a=012345678901234567 b=012345678901234568
as float: a=12345678901234567 b=12345678901234567
as int: a=2147483647 b=2147483647

Zend trys to convert the arguments to numbers if both 
arguments are strings. This is not good and its not a 


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2001-02-09 10:27 UTC]
Actually, this is a feature - it is described in the manual. Strings that look like numbers are converted to numbers. Large numbers - like the ones below may not convert perfectly from a string to a number.  Review the manual section on PHP types in general and strings in particular (

While this is a relatively subtle bug, you can ensure that you are dealing with strings by quoting the variables being compared or by using the === operator.  This behavior is exploited quite often in PHP scripts.  However, perhaps it would be nice if PHP generated an notice level error when it occured so that users have some recourse when it happens unexpectedly.

If you feel strongly about this, propose it to the developers as a feature request.  Post your request on the list (sub at - if you get no response, be polite but persistant. :)
 [2001-02-09 10:59 UTC] tom dot anheyer at berlinonline dot de
I think there is no reason to convert any type if both 
operands of the comparision are of the same type. It costs 
time and it's completely not necessary. This is a bug.

I can not see any description of this behavior in the 
manual. The string type section descibes only what is 
happen if a string is converted.

 [2001-02-09 11:10 UTC]
Incorrectly flagged as bogus.
 [2001-02-15 04:31 UTC]
This is a defined behavior (and does have strong reasons).  It's not a bug.
If you're interested in a byte-by-byte string comparison, you should use strcmp().
 [2001-02-15 04:32 UTC]
Ok, it should remain open as a documentation problem...
 [2001-02-15 05:07 UTC] tom dot anheyer at berlinonline dot de
Ok, I accept this. But I don't think that is a good idea 
to compare apples with pears with the answer 'yes they are 
fruit' without any warning.

 [2001-02-15 05:25 UTC]
this autoconversion is usefull when dealing with html form input
(for which php is used every once in a while afaik :)
as html has no numric input elements, just text 

maybe it would make sense to have this behaviour configurable
in the ini file, but i'm afraid that this would only increase the WTF
factor even more
 [2001-02-15 05:38 UTC] tom dot anheyer at berlinonline dot de
The conversation is useful. I know this because HTML form 
parameters, MySQL result sets are strings even if they are 
represent numbers.

But there some cases for which the conversation is not 
useful. If the result is MAXINT, MININT or NaN, it would 
be better not converting the operands and making a 
string comparision. A warning message whould be also 

 [2001-06-27 00:43 UTC]
I'm not sure why this is still open as a documentation bug. 

The string behavior is documented in:

and the == and === behavior is documented in:

PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Mon Sep 23 17:01:26 2019 UTC