Definitely evil :)
At 03:39 PM 6/2/2006, Michael Wallner wrote:
Antony Dovgal wrote:
On 03.06.2006 00:56, Andi Gutmans wrote:
Btw, any reason why we need all those redefinition of functions?
If it's just to save having to write TSRMLS_C then I'd prefer to
remove those macros. They just make d
Hello internals,
Bug #37667 describes a problem with returning an array from __get()
in write context.
property;
}
}
$c = new Class1();
$d = & $c->getProperty();
$d[] = 1;
var_dump($c);
?>
The engine sees the read to the array property as a write no matter
whether it is a read or write
Marcus Boerger wrote:
Hello Michael,
in streams api they at least make sense because the yuse the same
technology using in a bunch of zend functions to pass a bit more
information about the callee :-) - but here that is not done so i
also see no reason for that.
They were actually intended t
Andi Gutmans wrote:
Can you give a short summary of what the essence of the change is and
how the APIs have changed (Both the ones available to the PHP developer
and to the extension writer?)
The original README had a short example, but it became obsolete by porting
the code to HEAD. I will c
Antony Dovgal wrote:
On 03.06.2006 00:56, Andi Gutmans wrote:
Btw, any reason why we need all those redefinition of functions? If
it's just to save having to write TSRMLS_C then I'd prefer to remove
those macros. They just make debugging harder
I have to second that - those macros basically a
Hi Andi,
I don't understand this patch. Doesn't this completely remove printing
memory leaks? We never fixed this bug but as it was only relevant to the
debug version and dl() we were OK with it... Of course there's also the
option of not calling DL_UNLOAD().
Things got a bit crossed today :
I don't understand this patch. Doesn't this completely remove
printing memory leaks? We never fixed this bug but as it was only
relevant to the debug version and dl() we were OK with it... Of
course there's also the option of not calling DL_UNLOAD().
Andi
At 04:05 AM 6/1/2006, Dmitry Stogov w
At least the C++ standard guarantees that all remaining members of the
struct are initialized with their respective default value (which
would is be 0/NULL). So technically speaking, simply using {NULL} is
absolutely fine.
From a cursory glance it appears to me that it is the same with C, but
f
