#48012 [NEW]: String "0" conversion to boolean FALSE is not logical.

From: dave at ifox dot com Operating system: All PHP version: 5.3.0RC1 PHP Bug Type: Feature/Change Request Bug description: String "0" conversion to boolean FALSE is not logical. Description: ------------ PHP Developers, I typed a very logical explanation of why more careful thought should have been put into the addition of this conversion: "0" => FALSE but the submission failed and so I will try to reproduce it. When I learned about the exception of the string "0" converting to a boolean false, I had a sick feeling in my stomach. An entire team of language developers fell down the slippery slope caused by a handful of programmers in 2003 and 2004 that wanted to shorten their code, and thought that "0" -> TRUE was a bug. Every other language in existence converts a non-empty string to a boolean TRUE, because they prevail in this logic: the only meaning that SHOULD be derived from an alphanumeric string is its alphanumeric content, unless first cast to a numeric (or other) type. For a language that tries to bring in the best of other languages, PHP should at least mimic the logical behavior of those languages. I have edited dozens of web sites to fix well-structured code by skilled programmers that didn't expect this behavior, particularly when checking for the existence of strings from databases or user input (form POSTs). As an example: if ($_POST["uid"] && ...) { ... } now must be changed to: if (strlen($_POST["uid"]) && ...) { ... } and sometimes there are dozens of these in series. This begs programmers to be sloppy and just let "0" fail as an unusual case even when valid as input. And even skilled programmers can't be expected to read and catch this tiny exception in your documentation. There are other ramifications from not respecting the alphanumeric string for the purpose it was intended, to hold alphanumeric values. I will not expound here. The fact that FORM POSTs yield strings is not something to streamline in to the assumption that a user "meant" to enter an integer. Only a beginning programmer wanting a shortcut hack would expect or want this behavior. And what of " 0", "0 ", "00", "false", and "0.0"? They are respected! Originally I thought the "0" conversion was an attempt to make bool(string(FALSE)) == FALSE, but it already does since string(FALSE) == "" (although in other languages, it yields TRUE, because it is appropriate to conclude that the string representation of any boolean value has length and is therefore TRUE). JavaScript, as a common example, understands what an alphanumeric string is for: <script> if ('0') document.write('YES'); </script> This yields "YES", of course. Unfortunately there are now people out there posting that JavaScript is broken. But they are beginners, of course. A language should never make assumptions about a programmer's users' intent when providing input. If a user intends "0" as a string, why assume that is a numerical value? Don't you need to now assume all sorts of zero-value strings? I have developed two loosely-typed languages, and I made the choice to treat non-empty strings as TRUE. I find PHP for the web very usable, but I was completely surprised by this choice, and I'm sorry to say that it has resulted in high-quality code yielding unexpected subtle failures for its users. I modified PHP (14 or so changes in the Zend engine) to remove the feature and I made a patch. The ill stomach went away, and PHP now respects alphanumeric strings, but now I am uniquely conscious in a world of assumptions yielding unexpected results. I guess that's the beauty and curse of open source. What were the thought processes in creating this "feature"? Please consider its removal! Dave May Reproduce code: --------------- $str = "0"; if ($str) echo "TRUE"; else echo "FALSE"; --- From manual page: language.types.boolean --- Expected result: ---------------- TRUE Actual result: -------------- FALSE -- Edit bug report at http://bugs.php.net/?id=48012&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48012&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48012&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48012&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48012&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48012&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48012&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48012&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48012&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48012&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48012&r=support Expected behavior: http://bugs.php.net/fix.php?id=48012&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48012&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48012&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48012&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48012&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=48012&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48012&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48012&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48012&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48012&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48012&r=mysqlcfg