#41384 [NEW]: Clarification of == and === for strings.

From: hg at ecs dot soton dot ac dot uk Operating system: PHP version: Irrelevant PHP Bug Type: Documentation problem Bug description: Clarification of == and === for strings. Description: ------------ On http://uk.php.net/manual/en/language.operators.comparison.php My suggestion is that, at least, the start of the example should be changed to: <?php var_dump(0 == "a"); // 0 == 0 -> true var_dump("1" == "01"); // 1 == 1 -> true var_dump("1" === "01"); // 1 !== 1 -> false var_dump("0000e002073" == "0e2857"); // 0 == 0 -> true var_dump("0000e002073" === "0e2857"); // 0 !== 0 -> false The explanation is in the note I have submitted to the page; Warning, string comparison may be even stranger than you thought: <?php $a = "0e2"; $b = "0e3"; if ($a == $b) print '$a == $b'."\n"; // True if ($a === $b) print '$a === $b'."\n"; // False if ("000e002073" == "0e2857") print '"000e002073" == "0e2857"'."\n"; // True ?> outputs $a == $b "000e002073" == "0e2857" According to Table 15.4, since $a and $b are of the same type, it might have been expected that == and === gave the same result? Not necessarily. The clue is in the text below the table: "If you compare two numerical strings, they are compared as integers." Since these strings are numerical strings (in fact floats, if you hadn't worked it out yet), they are compared as integers. This is the behaviour we know and love about php, and I have no problem with it. I do have a problem that == and === give different answers for objects when "they are of the same type." I think that Table 15.4 gives no inkling of this. Table 15.5 might have made the situation clearer, but makes no distinction between == and ===. Of course, to be really safe, we should have been using strcmp() in any case, but it seems to be quite common that people use == for strings, so it should be pointed out. I am suggesting (by other mechanism) a change to the page, but in the meantime (or if it is rejected) this note may help. By the way, this was a real problem for me. If you are comparing a significant number of strings which happen to be hex, it is quite surprising to find that "000" == "0e0" whereas "000" != "0f0". I think I might start using things like "0e0" for username and password on websites to see what breaks :-) -- Edit bug report at http://bugs.php.net/?id=41384&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41384&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41384&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41384&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41384&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41384&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41384&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=41384&r=needscript Try newer version: http://bugs.php.net/fix.php?id=41384&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41384&r=support Expected behavior: http://bugs.php.net/fix.php?id=41384&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41384&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41384&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41384&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41384&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41384&r=dst IIS Stability: http://bugs.php.net/fix.php?id=41384&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41384&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41384&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41384&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=41384&r=mysqlcfg