php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #49348 Uninitialized ++$foo->bar; does not cause a notice (but ++$bar; does!)
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: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: BelStudent at yandex dot ru
New email:
PHP Version: OS:

 

 [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

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..?
 [2009-09-01 08:41 UTC] sjoerd@php.net
I was talking about this:
http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_execute.c?revision=286362&view=markup#l251

With ++$foo, type is BP_VAR_RW, which makes sense and gives a notice. With ++$this->foo, it is BP_VAR_W.
 [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-19 09:18 UTC] stas@php.net
Potential fix in this pull: https://github.com/php/php-src/pull/281
 [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
Automatic comment on behalf of stas
Revision: http://git.php.net/?p=php-src.git;a=commit;h=0c6d903ce7615a7197cb997d67d98058c3ec5d6a
Log: fix bug #49348 - issue notice on get_property_ptr_ptr when used for read
 [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).
 [2013-11-17 09:31 UTC] laruence@php.net
Automatic comment on behalf of stas
Revision: http://git.php.net/?p=php-src.git;a=commit;h=0c6d903ce7615a7197cb997d67d98058c3ec5d6a
Log: fix bug #49348 - issue notice on get_property_ptr_ptr when used for read
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Nov 21 10:01:29 2024 UTC