The title of this post is even less helpful (and less fair) than the title of the blog post which inspired it, so it should probably be viewed as parody. However, I do sadly have a file on my computer called hate.php containing a series of lines of valid PHP source code which produce unexpected and even perplexing results. Admittedly there are only 6 lines, and the behaviour of half of them is as documented, but I hold PHP to a higher standard than I would a “messy” language like Perl, so I thought this deserved a blog post.
Consider the line:
Admittedly it is strange to want to know whether zero is bigger than “null”, but as you could have two variables which you want to compare, and the values of those variables might end up being zero and null respectively (as actually happened to me in a piece of serious software) this is a case worth considering. To find out the answer you can just run this line, and PHP will output a value of 0 which can’t be considered wrong.
What would happen if you had compared your two variables the other way around, though, so that instead of asking “which is bigger, $a or $b” you are asking “which is bigger, $b or $a”. You might think that the answer would be the same, that the max() function is “commutative”, but in fact in this case:
you would get the answer null which does not === 0. Admittedly the two values do == each other, but you might be doing something like is_numeric() which will report differently for these two values.
Well, fortunately the PHP documentation explains this edge case, saying “If multiple values can be considered of the same size, the one that is listed first will be returned.” which is perhaps as simple a convention as you could hope for. Unfortunately, however, the same documentation page contains the rather contradictory statement that “If multiple arguments evaluate to 0, max() will return a numeric 0 if given, else the alphabetical highest string value will be returned.” In the second example I gave above, there are multiple (two) arguments which “evaluate to 0” but the output of the function is not “numeric 0”. Of course, it depends on your definition of “evaluate” but according to the type comparison table in the documentation, 0 and null should == each other.
Anyway, one thing the documentation is clear about is that the max() function can take more than just two arguments, so it is possible to run the following command:
for which PHP returns the value you should at this point expect, namely 0. It would seem almost impossible, then, that this reordered command:
returns anything other than null like the second example I gave above. You might guess that it suddenly decides to start returning 0 instead, but actually what it does is even weirder, it returns -1.
The documentation page makes no mention of null, so I’m not exactly sure what the principle at work here is. Trying:
produces the output -2 which shows this is not something special about the number -1, which lead me to try:
and see the response -1. Perhaps then there is just a bug which means that zeros are ignored if they occur directly after an initial null.
I could leave a comment on the relevant page of the documentation to warn people about this, but last time I left a comment on that site (pointing out a mistake in another comment) my comment got deleted soon after being accepted. The flawed comment I was trying to improve upon is still there, and it is disheartening to have my contribution removed while incorrect advice is left on the site to confuse people. Does anyone want to try reporting this as a bug, or pointing out at least to me why this is a feature?
