Bug #53971 [Asn->Csd]: isset() and empty() produce apparently spurious runtime error

Edit report at http://bugs.php.net/bug.php?id=53971&edit=1 ID: 53971 Updated by: dmitry@php.net Reported by: david at frankieandshadow dot com Summary: isset() and empty() produce apparently spurious runtime error -Status: Assigned +Status: Closed Type: Bug Package: Arrays related Operating System: Linux, Redhat Enterprise PHP Version: 5.3.5 Assigned To: dmitry Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: ------------------------------------------------------------------------ [2011-02-14 09:46:54] dmitry@php.net Automatic comment from SVN on behalf of dmitry Revision: http://svn.php.net/viewvc/?view=revision&revision=308315 Log: Fixed Bug #53971 (isset() and empty() produce apparently spurious runtime error) ------------------------------------------------------------------------ [2011-02-13 16:48:57] cataphract@php.net isset() should definitely not be emitting notices. Note that $string[1][0] is a relatively new construct (rev 301320), but it should follow the previous rules that empty and isset are silent. ------------------------------------------------------------------------ [2011-02-11 18:41:59] dtajchreber@php.net It looks like there was the change in behavior between 5.2.9 and 5.2.10. I don't know whether this was intentional or a side affect of another change. The difference can be seen here: http://codepad.org/iYcCCAkA /* 5.2.5 */ http://codepad.viper-7.com/msAbwQ /* 5.2.15RC3-dev */ I've reopened the ticket so this can be discussed. If it is intentional, it needs to be documented. ------------------------------------------------------------------------ [2011-02-09 21:30:10] david at frankieandshadow dot com I appreciate that this is the case. When you say "$obj->m[0] doesn't exist", yes I agree, BUT that is what the isset is testing for. If it SHOULD produce a runtime error, then (a) this is a very subtle non-upwards compatible change from 5.2, and (b) the example I quoted does NOT produce a runtime error so is a bug. (And producing a runtime error in these circumstances is terribly inconvenient, it means you can't test existence in one go but have to try each element individually). If it SHOULD NOT produce a runtime error then there is a problem with the larger code I have which follows this pattern and is doing so. There is a bug here one way or the other: either my larger program is wrong (but has worked for years with this code in it) or the example I put in the bug report is wrong in that it does not produce an error and never has. At present the behaviour is inconsistent. ------------------------------------------------------------------------ [2011-02-09 17:50:29] dtajchreber@php.net $obj->m is an empty string. You try to access a non-integer offset. Non-integer offsets are converted to integers. So in other words: $obj->m['a'] becomes $obj->m[0] $obj->m is an empty string and $obj->m[0] doesn't exist This behavior is documented here: http://us.php.net/manual/en/language.types.string.php "Warning Writing to an out of range offset pads the string with spaces. Non-integer types are converted to integer. Illegal offset type emits E_NOTICE. Negative offset emits E_NOTICE in write but reads empty string. Only the first character of an assigned string is used. Assigning empty string assigns NUL byte." Simplifying the problem: http://codepad.org/G31wr4oJ ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=53971 -- Edit this bug report at http://bugs.php.net/bug.php?id=53971&edit=1