php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #40692 Trying to use boolean as array doesn't give an error
Submitted: 2007-03-02 16:20 UTC Modified: 2015-06-08 20:47 UTC
From: smlerman at gmail dot com Assigned: cmb (profile)
Status: Duplicate Package: *General Issues
PHP Version: 5.2.1 OS: Any
Private report: No CVE-ID: None
 [2007-03-02 16:20 UTC] smlerman at gmail dot com
Description:
------------
If you try to use a boolean as an array (which most likely means an error occurred somewhere), the value is correctly returned as NULL, but no error message is reported. Obviously not a major problem, but it would make debugging a little easier.

Reproduce code:
---------------
<?php

var_dump(error_reporting());
$a = false;
var_dump($a[0]);

$b = (string)$a;
var_dump($b[0]);

?>

Expected result:
----------------
int(8191)
[Something like] Notice: Cannot use boolean as array in C:\Documents and Settings\...\boolean_array.php on line 5
NULL

Notice: Uninitialized string offset:  0 in C:\Documents and Settings\...\boolean_array.php on line 8
string(0) ""

Actual result:
--------------
int(8191)
NULL

Notice: Uninitialized string offset:  0 in C:\Documents and Settings\Scott\My Documents\Test Files\boolean_array.php on line 8
string(0) ""

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2007-03-03 15:58 UTC] 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

PHP is not type strict.
 [2007-03-03 16:57 UTC] smlerman at gmail dot com
Yeah, in 6 years of programming PHP, I never noticed that it isn't a strictly typed language. Trying to use an undefined offset of an array gives an error message. Trying to use a non-existant character index of a string gives an error message. So what is the boolean being converted to such that using an incorrect offset isn't an error?
 [2007-03-05 00:10 UTC] 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.
 [2007-03-05 00:22 UTC] 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 13:39 UTC] 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.
 [2013-10-28 19:58 UTC] krakjoe@php.net
-Status: Open +Status: Not a bug -Package: Feature/Change Request +Package: *General Issues
 [2013-10-28 19:58 UTC] 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 ...
 [2015-06-08 20:47 UTC] cmb@php.net
-Status: Not a bug +Status: Duplicate -Assigned To: +Assigned To: cmb
 [2015-06-08 20:47 UTC] cmb@php.net
> 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.
 
PHP Copyright © 2001-2017 The PHP Group
All rights reserved.
Last updated: Sun Nov 19 01:31:42 2017 UTC