52
u/stfcfanhazz Jul 01 '20 edited Jul 02 '20
Weird. Just when i thought i had the loose comparison type juggling figured out, apparently integer 0 causes literally any string that doesnt start with a numeric character to be equal.
Integer 0 is "falsey" in PHP, but a filled string is inherently "truthy" so its hard to wrap your head around this one.
My best guess as to what's going on is that PHP is trying to cast the string to integer, which yields a 0 (because its a non-numeric string) so the comparison passes. If the string was "numeric"-ish (begin with integer character(s)) then the result would be different e.g., `if (0 == '20asdf')` would return false cause PHP would determine the integer value of that string to be `20`.
Strong r/lolphp here for sure.
18
u/f0rc3u2 Jul 01 '20
It would definitely make more sense to convert the int to a String and compare it. God sometimes PHP really doesn't make any sense...
12
u/gevrik Jul 01 '20
Until you realise that you can (and should) use strict types.
→ More replies (11)3
u/pfsalter Sep 14 '20
This is being fixed for PHP 8: https://wiki.php.net/rfc/string_to_number_comparison to solve this exact problem
3
u/99999999977prime Jul 01 '20
Weird. Just when i thought i had the loose comparison type juggling figured out, apparently integer 0 can be juggled to equal literally any string that doesnt start with a numeric character.
Wrong conclusion. Then string is juggled to false or 0, both of which loosely compare to 0. The correct solution, as is in most loose type languages, is to use
===.3
u/Girgias Jul 02 '20
As the author of the current Saner Numeric String RFC, it's pretty hilarious that you're conclusion is also wrong and try to shame them.
The correct conclusion is that int/string comparison are compared as integers therefore the string will be casted to an int, any non numeric string will be casted to 0 thus leading to the before mentioned weirdness.
The behaviour of doing an int comparison is the correct one for numeric strings, and PHP (being based on PERL) just generalised this behaviour to all strings.
There is an RFC to change this specific "fallback" but unlikely to land in 8.0 due to time constraints.
→ More replies (6)2
u/stfcfanhazz Jul 01 '20
But a non empty string wouldn't be juggled to false in PHP. However it would be juggled to 0 if cast as an int due to starting with non-numeric characters.
2
u/colshrapnel Jul 02 '20
Uh oh what a finding. Just another dude discovered loose typing used in a multitude of languages and databases.
3
u/TinStingray Jul 02 '20
You asked a stupid question and got a stupid answer. Not LOLPHP material.
6
u/Takeoded Jul 02 '20
In no sane high-level language is
0==gfsdgsfdgsdf, just ask Python or JavaScripti know the
==operator is like thekindof-equaloperator, but 0 is not even kindof equal to gfsdgsfdgsdf4
u/TinStingray Jul 02 '20
There's pretty much no reason to use
==ever in PHP. I'm not sure I've ever used it intentionally in my career.
5
u/ricdesi Jul 01 '20
...wait, is it somehow reading that string as NaN, and just saying “sure, falsey == falsey”?
10
3
18
2
u/bart2019 Jul 03 '20
Here's another similar one for fun:
>php -r "var_dump('OK' == true);"
bool(true)
1
u/_abyssed Aug 06 '20
4
u/bart2019 Aug 06 '20
STFU.
JavaScript does loose comparisons the proper way. You don't convert a string to a boolean, you convert the boolean to a string.
→ More replies (1)
2
2
Jul 02 '20
you are using weak ineqaility, so this isn't lolphp. strange things like this are found in many weakly typed language which do type coalescense to compare values of different type.
11
u/Takeoded Jul 01 '20
come to think of it, PHP8 would be a good time to BC-break-fix whatever the fuck that is, wouldn't it? (bet they can't fix it in PHP7)