|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #55032 Treating null, boolean and numbers as arrays does not trigger an error
Submitted: 2011-06-11 02:19 UTC Modified: 2011-06-14 15:51 UTC
Avg. Score:3.8 ± 1.0
Reproduced:7 of 7 (100.0%)
Same Version:5 (71.4%)
Same OS:6 (85.7%)
From: cagret at gmail dot com Assigned:
Status: Duplicate Package: Variables related
PHP Version: 5.3.6 OS: Linux, Windows
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: cagret at gmail dot com
New email:
PHP Version: OS:


 [2011-06-11 02:19 UTC] cagret at gmail dot com
This bug is really annoying and generates many headeaches to millions of php 
developers. It's really hard to detect this bug sometimes, and that is because 
we have so much faith in PHP and we think that it's not possible that php would 
allow us to write such a nonsensical code and not throw an error, after all 
didn't we set the most strict error reporting you allow us to set?

This example code should be self explanatory:


error_reporting(-1); // The most strict error reporting.

$n = null;
echo $n[12]; // That should generate at least a E_NOTICE or E_STRICT warning.

$f = false;
echo $f[12]; // No error.

$t = true;
echo $t[12]; // No error, again.

$a = 4;
echo $a[12]; // Oh really, again no error? What a surprise!

$a = 4.44;
echo $a[12]; // And what do you think?! Guess! No error!


Please fix it ASAP.
Thank you for your time.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2011-06-13 19:14 UTC] cagret at gmail dot com
If implementing it is a performance problem (can't think of any other reason why it still hasn't been fixed), then you could at least give us an 
option, for example a php.ini option "check_types" that would be checking for such error. That would allow us to enable this option on Developer 
machines during testings and hopefully we would catch and fix all of these errors before uploading the code to the Production machine.
 [2011-06-14 15:51 UTC]
-Status: Open +Status: Duplicate
 [2011-06-14 15:51 UTC]
This is intended behaviour, per bug #41195.
 [2011-06-14 17:15 UTC] cagret at gmail dot com
Thank you for reading my comment with understanding.

We have an option to ignore/show E_NOTICE errors of undefined array indexes by 
setting error_reporting, why can't we have an option for not ignoring this 
behaviour? That could be easily fixed with no problems to backward compatibility, 
making it a behavior of E_STRICT or we could add an another E_ option for this.
 [2011-06-14 17:26 UTC] cagret at gmail dot com
What is the logic of keeping this bug as intended behavior? You do the opposite 
thing to undefined array indexes by showing an error, but here you do not do such 
thing. What is worse is that $array['no_such_key'] is a valid code even if there 
is no such key, but $true['asdf'] where $true is a boolean is just nonsense.

Do you want some real life examples of why this behavior generates many of bugs in 
our code and makes our life harder? Do you even understand the problem?
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Mon Mar 01 12:01:24 2021 UTC