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
