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

ID: 7387 Updated by: joey Reported By: delme@jumeaux.bc.ca Status: Assigned Bug Type: Documentation problem Assigned To: jmoore Comments: James: 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. Previous Comments: --------------------------------------------------------------------------- [2000-11-17 11:17:15] jmoore@php.net 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. --------------------------------------------------------------------------- [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... --------------------------------------------------------------------------- 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