During my upgrade to dotclear2, I noticed some notices about ""Indirect modification of overloaded property" and thought they are minor (notices…) and can be somehow ignored, bad idea

It seems that the known issues with setter/getters with array are more serious than I thought, being not really a fan of these magic methods, especially not for arrays or other non scalar data, I did not really "care", selber schuld

In the case of dotclear, the workaround is relatively easy:

<br />
class context<br />
{
  public $stack = array();</p>
 
  public function __set($name,$var)
  {
    $this->stack[$name] = $var;
  }
 
  public function __get($name)
  {
    if (!isset($this->stack[$name])) {
      return null;
    }
    return $this->stack[$name];
  }
}
 
	<p>$ctx = new context;<br />
$ctx->comment_preview = array();<br />
$ctx->comment_preview[&#8216;content&#8217;] = &#8216;&#8217;;<br />
$ctx->comment_preview[&#8216;rawcontent&#8217;] = &#8216;&#8217;;<br />
$ctx->comment_preview[&#8216;name&#8217;] = &#8216;&#8217;;<br />
$ctx->comment_preview[&#8216;mail&#8217;] = &#8216;&#8217;;<br />
$ctx->comment_preview[&#8216;site&#8217;] = &#8216;&#8217;;<br />
$ctx->comment_preview[&#8216;preview&#8217;] = false;<br />
$ctx->comment_preview[&#8216;remember&#8217;] = false;<br />
var_dump($ctx);</p>
 
	<p>$comment_preview = array();<br />
$comment_preview[&#8216;content&#8217;] = &#8216;&#8217;;<br />
$comment_preview[&#8216;rawcontent&#8217;] = &#8216;&#8217;;<br />
$comment_preview[&#8216;name&#8217;] = &#8216;&#8217;;<br />
$comment_preview[&#8216;mail&#8217;] = &#8216;&#8217;;<br />
$comment_preview[&#8216;site&#8217;] = &#8216;&#8217;;<br />
$comment_preview[&#8216;preview&#8217;] = false;<br />
$comment_preview[&#8216;remember&#8217;] = false;<br />
$ctx->comment_preview = $comment_preview;<br />
var_dump($ctx);<br />
 

The first initialiation will raise notices and fails (do not assign anything, as the error message says), the second works like a charm. This bug just confirms what I think about all these magic methods, don’t use them for non scalar unless someone put a gun on you.

The issue is known (thanks tony for the info). It is certainly due to the read/write access required by the array element change, but I do not know exactly how userland getter/setter work. I reopen an old bug (#36214), let see what will come out of it.

This release is mostly for windows users using other SAPI than CLI or (F)CGI. The bug is fixed in CVS already but I was lacking the time to release it. Pecl4win providing snapshots, it is half of a problem

The issue is actually a windows bug. No matter if I give or not the "b" flag to fopen, the write operations are not binary safe. It seems to be a known issue as many projects use the same trick:

 _setmode(_fileno(tfp), _O_BINARY );

PHP is forcing the binary mode in SAPI and CLI, that’s why the problem was not that easy to reproduce (apache or IIS debuggin on windows was not really my cup of tea .

I was trying to find some reference or bug reports about this issue but without much success, so far only people complaining about windows broken fopen. If anyone has detailed informations about this issue, please let me know.

As always you can fetch the DLLs from pecl4win or PECL.

• Full changelog
• Download