PHP 4.0 Bug #7387 Updated: weird problems with unquoted array subscripts

ID: 7387 Updated by: jmoore Reported By: delme@jumeaux.bc.ca Status: Assigned Bug Type: Documentation problem Assigned To: joey Comments: 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 php.net itself. Previous Comments: --------------------------------------------------------------------------- [2000-10-24 04:44:00] joey@php.net 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-10-22 19:45:09] lyric@php.net 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-22 15:10:31] stas@php.net moving to doc's problem, since it's clearly not engine bug but doc issue. --------------------------------------------------------------------------- [2000-10-22 14:52:00] delme@jumeaux.bc.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 http://www.php.net/version4/incompatibilities.php. this is a little dangerous. if we maybe introduced a null() *function* i could see it... --------------------------------------------------------------------------- [2000-10-22 10:57:47] lyric@php.net 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 $a["null"] 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; --------------------------------------------------------------------------- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. Full Bug description available at: http://bugs.php.net/?id=7387