php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #33941 overloading not working with arrays not stored as arrays
Submitted: 2005-08-01 05:48 UTC Modified: 2006-04-29 11:39 UTC
Votes:7
Avg. Score:4.6 ± 0.5
Reproduced:5 of 5 (100.0%)
Same Version:2 (40.0%)
Same OS:2 (40.0%)
From: gordon at heydon dot com dot au Assigned: dmitry (profile)
Status: Wont fix Package: Class/Object related
PHP Version: 5CVS OS: *
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
MUST BE VALID
Solve the problem:
20 - 16 = ?
Subscribe to this entry?

 
 [2005-08-01 05:48 UTC] gordon at heydon dot com dot au
Description:
------------
If using the __set() and __get() to store and manipulate arrays within a property, if the array is not being stored as an array then the array assignment will not work.

If in the example the property just has the value from the assignment stored without the serialization, so storing the array within the array this works.

Also the funny thing is that if you put echos within the __set() and __get the $obj->prop[5] = 'apple' does not output anything at all. It is like PHP is trying to guess what the __set() is doing and then doing that,

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

class ex {
  public function __get($prop) {
    return unserialize($this->fields[$prop]);
  }

  public function __set($prop, $value) {
    $this->fields[$prop] = serialize($value);
  }

  private $fields;
}

$obj = new ex;
$obj->prop = array(4 => 'pear');
$obj->prop[5] = 'apple';

var_dump($obj->prop);
?>


Expected result:
----------------
array(1) {
  [4]=>
  string(4) "pear"
  [5]=>
  string(5) "apple"
}


Actual result:
--------------
array(1) {
  [4]=>
  string(4) "pear"
}


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-08-01 12:42 UTC] stochnagara at hotmail dot com
I've tested this with the lastest win32 binary package. The bug is still present.

When __get prototype is changed to function & __get everything works fine.
 [2005-08-05 11:44 UTC] sniper@php.net
Dmitry "The Fixer", please check this out.

 [2005-08-05 12:06 UTC] dmitry@php.net
This is not fixable :(
 [2005-08-18 09:27 UTC] derick@php.net
Can we atleast make sure it gives a nice big warning on this? Now it merely produces some leaks:
<?php

        class Foo {
                function __set($name, $value)
                {
                        var_dump($name, $value);
                }
        }


        $f = new Foo();

        $f->bar[1] = 42;

produces:
derick@kossu:~$ php-6.0dev /tmp/foooo.php
/dat/dev/php/php-6.0dev/Zend/zend_execute.c(827) :  Freeing 0x08796494 (16 bytes), script=/tmp/foooo.php
/dat/dev/php/php-6.0dev/Zend/zend_execute.c(1005) :  Freeing 0x0879643C (35 bytes), script=/tmp/foooo.php
/dat/dev/php/php-6.0dev/Zend/zend_hash.c(383) : Actual location (location was relayed)
/dat/dev/php/php-6.0dev/Zend/zend_execute.c(1060) :  Freeing 0x087963DC (44 bytes), script=/tmp/foooo.php
/dat/dev/php/php-6.0dev/Zend/zend_API.c(712) : Actual location (location was relayed)
Last leak repeated 1 time
/dat/dev/php/php-6.0dev/Zend/zend_execute.c(1057) :  Freeing 0x087842CC (16 bytes), script=/tmp/foooo.php
=== Total 5 memory leaks detected ===

 [2005-09-09 14:18 UTC] fanfatal at fanfatal dot pl
In PHP 5.0.4 this bug has been corrected

Greatings ;-)
...
 [2005-09-17 01:53 UTC] tony2001@php.net
For the record, I don't see any memleaks with 5.0/5.1/6.0 now.
 [2006-04-29 11:39 UTC] mike@php.net
Who closed that bug?
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 09:01:26 2024 UTC