Uninitialized ++$foo->bar; does not cause a notice (but ++$bar; does!)

Bug #49348

Submitted:

2009-08-24 16:21 UTC

Modified:

2013-02-20 08:35 UTC

Votes:	4
Avg. Score:	3.2 ± 1.1
Reproduced:	3 of 3 (100.0%)
Same Version:	2 (66.7%)
Same OS:	2 (66.7%)

From:

BelStudent at yandex dot ru

Assigned:

stas (profile)

Status:

Closed

Package:

Scripting Engine problem

PHP Version:

5.*, 6

OS:

Private report:

CVE-ID:

None

[2009-08-24 16:21 UTC] BelStudent at yandex dot ru

Description:
------------
Usually, if you try to do this: ++$num, then thrown notice, that the "Undefined variable: num". This helps avoid errors. 
But if you have class and you're trying to do so ++$this->num num nowhere and had not previously identified, then the issue no warnings and notices. 

Accidentally deleted in the symbol and received ++$this->nu, and then climbed into hell knows what mistakes to find this place and correct to ++$this->num took several hours. So I am very concerned about the issue: how to do so were given notice, if you try to do something with uninitialized (unknown) variable in the class?

Reproduce code:
---------------
<?php
class A
{ public function __construct()
    {   ++$this->num;
    }
}
new A();
?>

Expected result:
----------------
Undefined property:  A::$num


Actual result:
--------------
empty

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports

[2009-08-25 07:13 UTC] gwynne@php.net

Actually, this is a valid problem; the problem described by bug #21008 is a different issue. There seems to be some confusion as to whether it should be fixed or not, but it's neither a duplicate nor bogus.

Specifically, bug #21008 describes an issue with setting a variable to a value, where this report describes an issue with updating a variable. These are two distinct operations, and are handled differently.

More to the point, the following code throws a notice:
<?php
++$n;
?>

That the code described by this bug doesn't is an inconsistency.

[2009-08-25 08:18 UTC] jani@php.net

Reopened, Gwynne's arguments are rock solid. :)

[2009-08-27 21:06 UTC] sjoerd@php.net

In _get_zval_cv_lookup(), type is BP_VAR_W, while it should be BP_VAR_RW for the example code.

[2009-08-31 22:12 UTC] jani@php.net

# svn log -r100312 zend_object_handlers.c
------------------------------------------------------------------------
r100312 | stas | 2002-10-20 22:22:04 +0300 (Sun, 20 Oct 2002) | 2 lines

looks like this message should go

---

Stas, care to explain? Uncommenting that will bring back the notice.

And Sjoerd, what did you mean with that comment..?

[2013-02-19 04:59 UTC] stas@php.net

The problem here is that get_property_ptr_ptr does not produce notices. It doesn't 
because it does not know the fetch type - in some cases it's BP_VAR_W, then it 
shouldn't produce notice, in some it's BP_VAR_RW and then it should. However 
get_property_ptr_ptr doesn't have a parameter to pass this info.

Looks like such parameter needs to be added...

[2013-02-20 08:35 UTC] dmitry@php.net

I think the fix is fine, but it may go only into 5.5 and above.

[2013-02-21 08:58 UTC] stas@php.net

-Status: Assigned +Status: Closed

[2013-03-29 20:07 UTC] bugs dot php dot net at majkl578 dot cz

The message is not consistent with the other one triggered in similar case.

Consider the following code:
$x = new stdClass();
echo $x->foo++;
echo $x->bar;

It triggers two notices:
Notice: Undefined property: foo
Notice: Undefined property: stdClass::$bar

The first one was added by fix for this bug and is wrong. It should be same as the other one (should contain classname and dollar).