Edit report at http://bugs.php.net/bug.php?id=53971&edit=1
ID: 53971
Updated by: dmi...@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] dmi...@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] cataphr...@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] dtajchre...@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] dtajchre...@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
