php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

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
View Developer Edit
 [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: Mon Dec 30 15:01:28 2024 UTC