|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #7387 weird problems with unquoted array subscripts
Submitted: 2000-10-21 23:32 UTC Modified: 2001-05-23 01:13 UTC
From: delme at jumeaux dot bc dot ca Assigned: jeroen (profile)
Status: Closed Package: Documentation problem
PHP Version: 4 (any) OS: linux 2.2
Private report: No CVE-ID: None
 [2000-10-21 23:32 UTC] delme at jumeaux dot bc dot ca
I think it's better simply to demonstrate this bug or bugs than to try and explain it.

given this code:

$test[Null]='a test with capitals';
$test[null]='a test with all lower case';
print "\$test[Null] = '";
print $test[Null];
print "'<BR>\$test[Null] (interpolated) = '$test[Null]'<BR>";
print "\$test[null] = '";
print $test[null];
print "'<BR>\$test[null] (interpolated) = '$test[null]'<BR>";
print "!\$math[Null] = '";
print !$empty[Null];
print "'<BR>!\$filled[Null] = '";
print !$filled[Null];
print "'<BR>";

under php3 i got what i would expect:

$test[Null] = 'a test with capitals'
$test[Null] (interpolated) = 'a test with capitals'
$test[null] = 'a test with all lower case'
$test[null] (interpolated) = 'a test with all lower case'
!$math[Null] = '1'
!$filled[Null] = '0'

but under 4.0.3pl1 (and 4.0.1pl2) i get:

$test[Null] = 'a test with all lower case'
$test[Null] (interpolated) = ''
$test[null] = 'a test with all lower case'
$test[null] (interpolated) = ''
!$math[Null] = '1'
!$filled[Null] = ''

something is very wrong.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2000-10-22 10:57 UTC]
Two distinct issues:

a) The problem starts with the fact that >>null<<, in all it's forms, is a magic word with a single unique value. Thus $a[null] is the same variable as $a[Null], but NOT the same as $a["Null"].  The problem is that 

  "  $a[null]  "

is being read as 


which is probably the best way to handle this single ambigious case. SOLUTION: don't use NULL as an array index without quoting it.

b) the difference is simply in the way a boolean is printed to the screen. A true is now displayed as '1', a false is now '' (the empty string). I'm not sure why that was changed. SOLUTION: echo ($cond)?1:0;

 [2000-10-22 14:52 UTC] delme at jumeaux dot bc dot ca
i must ask, then - why has the bareword `null' suddenly picked up a special meaning to the scripting engine?  this seems like a *bad* design move to me, since it means that this bareword suddenly behaves differently than before.  it's also not consistent - *are* there other barewords that have special meanings in similar contexts?

also, it's not mentioned at  this is a little dangerous.

if we maybe introduced a null() *function* i could see it...

 [2000-10-22 15:10 UTC]
moving to doc's problem, since it's clearly not engine bug but doc issue.
 [2000-10-22 19:45 UTC]
It won't work properly with any reserved word, which brings me back to the point : you should always quote constant strings.  The only reason that it works at all is the parser is fixing your mistakes for you.  If you set your

  error_reporting = E_ALL

in your php.ini (and restart php), for the code

  $a[word] = "foo";

you'll see the warning

  Warning: Use of undefined constant word - assumed 'word' in /var/www/html/test2.php on line 3

I'll leave this issue open for someone from the documentation team to catch up with later.
 [2000-10-24 04:44 UTC]
This is neither a bug in PHP, nor a doc bug...I will make
the incompat entry more explicit as soon as I can get to the
CVS, but you can see from the last comment what the problem
is: you are using a predefined constant as a key in an assoc.
array. This would be termed, at best, as "undefined".
 [2000-11-17 11:17 UTC]
Maybe we should look at documenting how the engine corrects bad coding. We often get questions on #php about the engine correcting unquoted string constants and any other behaviour like this. I cant think of any others now but maybe a new chapter on debugging troublesome code or common errors etc is necessary in the manual. This might belong in the FAQ but I think a chapter in the docs wouldnt go amiss. Maybe another thing we should think about doing is including the FAQ in the manual as well as on itself.
 [2000-12-09 12:22 UTC]
  Since you have a better idea of exactly what it is you
want to document, I'm moving this to you. Close it whenever
you think it is sufficently documented.
 [2001-05-06 11:23 UTC]
Any progress on this?
 [2001-05-20 21:27 UTC]
I am currently writing the section 'why is $foo[bar] bad' in the arrays section. It will adress this problem, so that in the future you can say: RTFM
 [2001-05-23 00:11 UTC]
Included big warning in manual about this.
 [2001-05-23 01:13 UTC]
Included big warning in manual about this.
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Wed Oct 21 11:01:24 2020 UTC