Req #40692 [Nab->Dup]: Trying to use boolean as array doesn't give an error
| From: | cmb@php.net | Date: | Mon, 08 Jun 2015 20:47:52 +0000 |
| Subject: | Req #40692 [Nab->Dup]: Trying to use boolean as array doesn't give an error | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-193218@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=40692&edit=1
ID: 40692
Updated by: cmb@php.net
Reported by: smlerman at gmail dot com
Summary: Trying to use boolean as array doesn't give an error
-Status: Not a bug
+Status: Duplicate
Type: Feature/Change Request
Package: *General Issues
Operating System: Any
PHP Version: 5.2.1
-Assigned To:
+Assigned To: cmb
Block user comment: N
Private report: N
New Comment:
> Not only is it expected it is the only reasonable thing _to
> expect_.
I disagree that the following behavior is the only reasonable
thing to expect:
false[42] // => NULL (without notice/warning)
Anyhow, this is a duplicate of request #37676.
Previous Comments:
------------------------------------------------------------------------
[2013-10-28 19:58:29] krakjoe@php.net
As has already been explained, the behaviour exhibited is expected.
Not only is it expected it is the only reasonable thing _to expect_.
The only time you can expect a type to be coerced is upon passing it to the engine _for
manipulation_ or upon explicit casting:
<?php
var_dump(error_reporting());
$a = false;
var_dump($a[0]);
$b = (string)$a;
var_dump($b[0]);
?>
If the engine had cast $a to anything on line 2, _that_ would be unexpected;
if it had been done as if by magic then PHP would be unusable (because you would never know what
type any variable was from one line to the next),
if it had been done by the call to var_dump implicitly then var_dump would be useless for
it's intended purpose.
PHP is not strictly typed, end of story :)
Closing request ...
------------------------------------------------------------------------
[2013-08-20 08:33:54] requinix@php.net
Related To: Bug #65484
------------------------------------------------------------------------
[2007-03-05 13:39:00] smlerman at gmail dot com
Here's another test case that shows that something isn't quite right with implicit
conversions.
<?php
var_dump(error_reporting());
$a = 12345;
var_dump($a[0]); // Should cast to string or possibly array
var_dump($a{0}); // Should cast to string
$b = (string)$a;
var_dump($b[0]);
$c = (array)$a;
var_dump($c[0]);
?>
Results:
int(8191)
NULL
NULL
string(1) "1"
int(12345)
So $a isn't being converted to a string or array if you do $a[0]. It also isn't converted
to a string if you do $a{0}, and I have no idea what else it could reasonably convert to. I never
rely on these implicit conversions, so I have no real personal interest in whether the behavior
stays the same as it is now or if the conversions are fixed, but some kind of error message, even a
notice for an undefined index for something like $a['foo'], would help with debugging this
kind of programmer mistake.
------------------------------------------------------------------------
[2007-03-05 00:22:42] smlerman at gmail dot com
Actually, as my code shows, you do not get false, you get NULL, so it's obviously not doing a
normal conversion to an array. I'm not disputing the value of the expression, since it makes
perfect sense to me that the value of a non-existent variable should be NULL. In all other cases,
though, it also gives a notice, which is what would be nice to have.
------------------------------------------------------------------------
[2007-03-05 00:10:28] iliaa@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to
report
a bug at http://bugs.php.net/how-to-report.php
(string)false == ""
"" does not have offset 0 and therefor you get a warning message.
(array)false == array(0 => false);
and when you access element 0 of this array you get false in return.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=40692
--
Edit this bug report at https://bugs.php.net/bug.php?id=40692&edit=1