3 ms·
I believe "high quality PHP" is an oxymoron. It's just impossible to be aware of all the pitfalls PHP contains. Here is just one example among many: > if( '333
by heron87 13y ago
I believe "high quality PHP" is an oxymoron. It's just impossible to be aware of all the pitfalls PHP contains. Here is just one example among many:
> if( '33333333333333333333' == '33333333333333333334' ) echo "equal";
Output: "equal"
The "reason" for this very odd behaviour is that the two strings are automatically converted into integers, which leads to an int overflow, which PHP ignores (ignoring errors is very PHP specific) by guessing that the two "numbers" must be equal. I'm sure they even call this a feature...
- blindhippo 13y agoI would argue this isn't odd behavior - it's doing exactly what you asked it to do, and giving you the proper result. If this is incorrect, do it properly. If you're encountering this pitfall, the problem isn't the tool being used, but the person writing the code.
- jiggy2011 13y agoI just tested this (PHP 5.4) and I don't get this behaviour. In this example the two are compared as strings not integers so are not equal. PHP does not automatically convert types unless you do something like this: if( 33333333333333333333 == '33333333333333333334' ) But here the problem is the integer overflow not specifically the type conversions. You are going to get weird behaviour no matter what you do because you don't have enough bits to store that number. If you want to use numbers this size then you are going to need some type other than the standard int.
- DCoder 13y agoNot entirely true. PHP definitely tries to perform a numeric comparison on two strings if it thinks they are both numerical strings, but this behaviour changed in PHP 5.4 [0]. heron87's scenario was reported as a bug [1], changed in PHP 5.4 and caused new problems [2]. See the string comparison routine in 5.3 [3] and 5.4 [4]. The new implementation still inspects the strings to see if they are numeric and then tries to do a numeric equality check rather than string equality check, leading to amusing tricks like var_dump("0xFF" == "255.0"); // true! But if both values overflow the long type and their double representations are equal, the new implementation falls back to actual string equality. A quick check at [5] shows that both values heron87 compared have identical double representations, assuming (sizeof double == 8), so the new representation detects the long overflow, then it sees that double representations are also identical, and then it returns to string equality rather than numeric equality. The old implementation did not consider long overflow and ended up comparing the numeric values. [0] http://3v4l.org/a0nKq http://3v4l.org/a0nKq [1] https://bugs.php.net/bug.php?id=54547 https://bugs.php.net/bug.php?id=54547 [2] https://bugs.php.net/bug.php?id=62097 https://bugs.php.net/bug.php?id=62097 [3] https://github.com/php/php-src/blob/PHP-5.3/Zend/zend_operators.c#L1992 https://github.com/php/php-src/blob/PHP-5.3/Zend/zend_operat... [4] https://github.com/php/php-src/blob/5.4/Zend/zend_operators.c#L2039 https://github.com/php/php-src/blob/5.4/Zend/zend_operators.... [5] http://babbage.cs.qc.cuny.edu/IEEE-754/index.xhtml http://babbage.cs.qc.cuny.edu/IEEE-754/index.xhtml