php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #40465 var_dump() printing details of private and protected object properties
Submitted: 2007-02-13 16:21 UTC Modified: 2010-12-20 12:24 UTC
From: wharmby at uk dot ibm dot com Assigned: iliaa (profile)
Status: Closed Package: Scripting Engine problem
PHP Version: 5CVS-2007-02-13 (CVS) OS: Windows XP
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 this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: wharmby at uk dot ibm dot com
New email:
PHP Version: OS:

 

 [2007-02-13 16:21 UTC] wharmby at uk dot ibm dot com
Description:
------------
I have come across the following behaviour while reviewing
the var_dump code which is either a bug or the code needs 
tidying up. The output certainly does not tally with the 
behaviour suggested by the code.

My reading of the code in php_array_element_dump() is that
if an Object with private or protected properties is cast to
an array and then dumped using var_dump() then no private or
protected fields should be dumped (previous defects suggest otherwise but the code suggests they should not be printed)

The code in  php_array_element_dump() is as follows:

level = va_arg(args, int);

if (hash_key->nKeyLength==0) { /* numeric key */
    php_printf("%*c[%ld]=>\n", level + 1, ' ', hash_key->h);
} else { /* string key */
    if (va_arg(args, int) && hash_key->arKey[0] == '\0') { 
        /* XXX: perhaps when we are inside the class we
         * should permit access to private & protected 
         * values
	 */
	return 0;
    }
    php_printf("%*c[\"", level + 1, ' ');
    PHPWRITE(hash_key->arKey, hash_key->nKeyLength - 1);
    php_printf("\"]=>\n");
}

However, because of a logic error in php_var_dump()the
2nd argument does not get passed to php_array_element_dump()
and so we print out the details of private and protected 
fields.

Assuming the intention is NOT to print out private or protected fileds the patch to correct the var_dump_code 
is as follows:

    http://www.pastebin.ca/353743

However, previous defects have been raised on this subject
and closed as "Expected Behaviour". If it is the case that all fields should be printed by var_dump to aid debug then
the code in php_array_element_dump() and php_var_dump() should be cleaned up as in the following patch: 

    http://www.pastebin.ca/353787

Both patches built against CVS code as of 15:30 GMT on 13th Feb 2007.


Reproduce code:
---------------
<?php

class foo
{
public $a = 10;
private $b = 20;
public $c = 40;
protected $d = 50;
public $e = 60;
}

$obj = new foo();
var_dump($obj);

$fooarr = (array)$obj;
var_dump($fooarr);
 
?>


Expected result:
----------------
object(foo)#1 (5) {
  ["a"]=>
  int(10)
  ["b:private"]=>
  int(20)
  ["c"]=>
  int(40)
  ["d:protected"]=>
  int(50)
  ["e"]=>
  int(60)
}
array(5) {
  ["a"]=>
  int(10)
  ["c"]=>
  int(40)
  ["e"]=>
  int(60)
}

Actual result:
--------------
object(foo)#1 (5) {
  ["a"]=>
  int(10)
  ["b:private"]=>
  int(20)
  ["c"]=>
  int(40)
  ["d:protected"]=>
  int(50)
  ["e"]=>
  int(60)
}
array(5) {
  ["a"]=>
  int(10)
  [" foo b"]=>
  int(20)
  ["c"]=>
  int(40)
  [" * d"]=>
  int(50)
  ["e"]=>
  int(60)
}


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2007-02-13 18:44 UTC] derick@php.net
Just FYI: var_dump should show the private and protected properties.
 [2007-02-13 19:05 UTC] wharmby at uk dot ibm dot com
Thanks Derick. I had assumed as much from comments in previous defects on var_dump(). var_dump() is a debug aid 
rather than something a PHP application should be using 
and if it did NOT print out details regarding private and protected fields that would be a pain. 

Which means that the 2nd patch attached is the one which is needed here to remove the spurious and bogus code.
 [2007-02-13 19:08 UTC] wharmby at uk dot ibm dot com
btw.. Given that the code behaves in the intended manner removing the spurious code in the HEAD (PHP 6) stream only would probably suffice here.
 [2007-02-16 03:42 UTC] iliaa@php.net
This bug has been fixed in CVS.

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.

Thanks for the patch.
 [2010-12-20 12:24 UTC] jani@php.net
-Package: Tidy +Package: Scripting Engine problem -Assigned To: +Assigned To: iliaa
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Mar 19 09:01:30 2024 UTC