[PHP-CVS] Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/NEWS branches/PHP_5_3/Zend/zend_API.c trunk/NEWS trunk/Zend/zend_API.c
On Tue, Feb 28, 2012 at 10:38 AM, Xinchen Hui wrote:
> On Tue, Feb 28, 2012 at 1:10 AM, Anthony Ferrara wrote:
>> I initially looked at the final fix when I discovered the issue.
>> Follow me out on this. This is the current code as-implemented in
>> r323563:
>>
>> 265 zval *obj;
>> 266 MAKE_STD_ZVAL(obj);
>> 267 if (Z_OBJ_HANDLER_P(*arg, cast_object)(*arg, obj, type
>> TSRMLS_CC) == SUCCESS) {
>> 268 zval_ptr_dtor(arg);
>> 269 *arg = obj;
>> 270 *pl = Z_STRLEN_PP(arg);
>> 271 *p = Z_STRVAL_PP(arg);
>> 272 return SUCCESS;
>> 273 }
>> 274 efree(obj);
>>
>> The issue that I originally identified (overwriting the argument
>> pointer) is still happening. Is there any reason for overwriting the
>> arg pointer? Wouldn't it be better to just do the Z_STRLEN_PP and
>> Z_STRVAL_PP operations on obj instead, and zval_ptr_dtor it as well
> Oops, you are right.. thanks for pointing this out.
> :)
Sorry, I miss-read your words. so I revoke my previous words.
the reason for why overwriting arg, is we should record that new temp
zval(IS_STRING), then release it while doing cleanup parameters.
and also, fo 5.3, no p and pl paramters.
thanks
>> (instead of efree, as that way if a reference is stored somewhere it
>> won't result in a double free, or a segfault for accessing freed
>> memory)?
>>
>> Thanks,
>>
>> Anthony
>>
>> On Mon, Feb 27, 2012 at 11:39 AM, Xinchen Hui wrote:
>>> Sent from my iPad
>>>
>>> 在 2012-2-28，0:10，Anthony Ferrara 写道：
>>>
Out of curiosity, why are you changing it to copy the object for the
result of the cast operation? cast_object should init the result
zval, so why go through the step of copying the starting object to
>>> plz look at the final fix： r323563
>>>
>>> thanks
r323563
Wouldn't it be easier just to do:
if (Z_OBJ_HANDLER_PP(arg, cast_object)) {
zval *result;
ALLOC_ZVAL(result);
if (Z_OBJ_HANDLER_P(*arg, cast_object)(*arg, result, type TSRMLS_CC)
== SUCCESS) {
zval_ptr_dtor(arg);
*pl = Z_STRLEN_PP(result);
*p = Z_STRVAL_PP(result);
zval_ptr_dtor(result);
return SUCCESS;
}
zval_ptr_dtor(result);
}
Keeping both completely separate, and not having the possibility of
corrupting the arg object pointer? As it is right now (with the patch
in the first mail), wouldn't the possibility still exist of nuking the
arg object pointer which could be used elsewhere (and hence cause the
memory leak and segfault when that variable is referenced again)?
(Un tested as of yet, just throwing it out there as it seems kind of
weird to overwrite the arg pointer for what seems like no reason)...
Anthony
On Mon, Feb 27, 2012 at 10:22 AM, Richard Lynch wrote:
> On Mon, February 27, 2012 2:31 am, Laruence wrote:
>> On Mon, Feb 27, 2012 at 4:00 PM, Dmitry Stogov
>> wrote:
>>> Hi Laruence,
>>>
>>> The attached patch looks wired. The patch on top of it (r323563)
>>> makes it
>>> better. However, in my opinion it fixes a common problem just in a
>>> single
>>> place. Each call to __toString() that makes "side effects" may cause
>>> the
>>> similar problem. It would be great to make a "right" fix in
>>> zend_std_cast_object_tostring() itself, but probably it would
>>> require API
>> Hi:
>> before this fix, I thought about the same idea of that.
>>
>> but, you know, such change will need all exts who implmented
>> their own cast_object handler change there codes too.
>>
>> for now, I exam the usage of std_cast_object_tostring, most of
>> them do the similar things like this fix to avoid this issues(like
>> ZEND_CAST handler).
>>
>> so I think, maybe it's okey for a temporary fix :)
>
> Perhaps a better solution would be to make a NEW function that uses
> zval** and deprecate the old one with memory leaks.
>
> Old extensions remain functional, new extension consume less memory.
>
> (This presumes I actually understand the issue, which is questionable.)
>
> --
> brain cancer update:
> http://richardlynch.blogspot.com/search/label/brain%20tumor
> Donate:
> https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
>
> --
> 惠新宸 laruence
> Senior PHP Engineer
> http://www.laruence.com
--
惠新宸 laruence
Senior PHP Engineer
http://www.laruence.com
--
PHP CVS Mailing List
[PHP-CVS] Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/NEWS branches/PHP_5_3/Zend/zend_API.c trunk/NEWS trunk/Zend/zend_API.c
On Tue, Feb 28, 2012 at 1:10 AM, Anthony Ferrara wrote:
> I initially looked at the final fix when I discovered the issue.
> Follow me out on this. This is the current code as-implemented in
> r323563:
>
> 265 zval *obj;
> 266 MAKE_STD_ZVAL(obj);
> 267 if (Z_OBJ_HANDLER_P(*arg, cast_object)(*arg, obj, type
> TSRMLS_CC) == SUCCESS) {
> 268 zval_ptr_dtor(arg);
> 269 *arg = obj;
> 270 *pl = Z_STRLEN_PP(arg);
> 271 *p = Z_STRVAL_PP(arg);
> 272 return SUCCESS;
> 273 }
> 274 efree(obj);
>
> The issue that I originally identified (overwriting the argument
> pointer) is still happening. Is there any reason for overwriting the
> arg pointer? Wouldn't it be better to just do the Z_STRLEN_PP and
> Z_STRVAL_PP operations on obj instead, and zval_ptr_dtor it as well
Oops, you are right.. thanks for pointing this out.
:)
> (instead of efree, as that way if a reference is stored somewhere it
> won't result in a double free, or a segfault for accessing freed
> memory)?
>
> Thanks,
>
> Anthony
>
> On Mon, Feb 27, 2012 at 11:39 AM, Xinchen Hui wrote:
>> Sent from my iPad
>>
>> 在 2012-2-28，0:10，Anthony Ferrara 写道：
>>
>>> Out of curiosity, why are you changing it to copy the object for the
>>> result of the cast operation? cast_object should init the result
>>> zval, so why go through the step of copying the starting object to
>> plz look at the final fix： r323563
>>
>> thanks
>>> r323563
>>> Wouldn't it be easier just to do:
>>>
>>> if (Z_OBJ_HANDLER_PP(arg, cast_object)) {
>>> zval *result;
>>> ALLOC_ZVAL(result);
>>> if (Z_OBJ_HANDLER_P(*arg, cast_object)(*arg, result, type TSRMLS_CC)
>>> == SUCCESS) {
>>> zval_ptr_dtor(arg);
>>> *pl = Z_STRLEN_PP(result);
>>> *p = Z_STRVAL_PP(result);
>>> zval_ptr_dtor(result);
>>> return SUCCESS;
>>> }
>>> zval_ptr_dtor(result);
>>> }
>>>
>>> Keeping both completely separate, and not having the possibility of
>>> corrupting the arg object pointer? As it is right now (with the patch
>>> in the first mail), wouldn't the possibility still exist of nuking the
>>> arg object pointer which could be used elsewhere (and hence cause the
>>> memory leak and segfault when that variable is referenced again)?
>>>
>>> (Un tested as of yet, just throwing it out there as it seems kind of
>>> weird to overwrite the arg pointer for what seems like no reason)...
>>>
>>> Anthony
>>>
>>>
>>>
>>> On Mon, Feb 27, 2012 at 10:22 AM, Richard Lynch wrote:
On Mon, February 27, 2012 2:31 am, Laruence wrote:
> On Mon, Feb 27, 2012 at 4:00 PM, Dmitry Stogov
> wrote:
>> Hi Laruence,
>>
>> The attached patch looks wired. The patch on top of it (r323563)
>> makes it
>> better. However, in my opinion it fixes a common problem just in a
>> single
>> place. Each call to __toString() that makes "side effects" may cause
>> the
>> similar problem. It would be great to make a "right" fix in
>> zend_std_cast_object_tostring() itself, but probably it would
>> require API
> Hi:
> before this fix, I thought about the same idea of that.
>
> but, you know, such change will need all exts who implmented
> their own cast_object handler change there codes too.
>
> for now, I exam the usage of std_cast_object_tostring, most of
> them do the similar things like this fix to avoid this issues(like
> ZEND_CAST handler).
>
> so I think, maybe it's okey for a temporary fix :)
Perhaps a better solution would be to make a NEW function that uses
zval** and deprecate the old one with memory leaks.
Old extensions remain functional, new extension consume less memory.
(This presumes I actually understand the issue, which is questionable.)
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
惠新宸 laruence
Senior PHP Engineer
http://www.laruence.com
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-CVS] Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/NEWS branches/PHP_5_3/Zend/zend_API.c trunk/NEWS trunk/Zend/zend_API.c
I initially looked at the final fix when I discovered the issue.
Follow me out on this. This is the current code as-implemented in
r323563:
265 zval *obj;
266 MAKE_STD_ZVAL(obj);
267 if (Z_OBJ_HANDLER_P(*arg, cast_object)(*arg, obj, type
TSRMLS_CC) == SUCCESS) {
268 zval_ptr_dtor(arg);
269 *arg = obj;
270 *pl = Z_STRLEN_PP(arg);
271 *p = Z_STRVAL_PP(arg);
272 return SUCCESS;
273 }
274 efree(obj);
The issue that I originally identified (overwriting the argument
pointer) is still happening. Is there any reason for overwriting the
arg pointer? Wouldn't it be better to just do the Z_STRLEN_PP and
Z_STRVAL_PP operations on obj instead, and zval_ptr_dtor it as well
(instead of efree, as that way if a reference is stored somewhere it
won't result in a double free, or a segfault for accessing freed
memory)?
Thanks,
Anthony
On Mon, Feb 27, 2012 at 11:39 AM, Xinchen Hui wrote:
> Sent from my iPad
>
> 在 2012-2-28，0:10，Anthony Ferrara 写道：
>
>> Out of curiosity, why are you changing it to copy the object for the
>> result of the cast operation? cast_object should init the result
>> zval, so why go through the step of copying the starting object to
> plz look at the final fix： r323563
>
> thanks
>> r323563
>> Wouldn't it be easier just to do:
>>
>> if (Z_OBJ_HANDLER_PP(arg, cast_object)) {
>> zval *result;
>> ALLOC_ZVAL(result);
>> if (Z_OBJ_HANDLER_P(*arg, cast_object)(*arg, result, type TSRMLS_CC)
>> == SUCCESS) {
>> zval_ptr_dtor(arg);
>> *pl = Z_STRLEN_PP(result);
>> *p = Z_STRVAL_PP(result);
>> zval_ptr_dtor(result);
>> return SUCCESS;
>> }
>> zval_ptr_dtor(result);
>> }
>>
>> Keeping both completely separate, and not having the possibility of
>> corrupting the arg object pointer? As it is right now (with the patch
>> in the first mail), wouldn't the possibility still exist of nuking the
>> arg object pointer which could be used elsewhere (and hence cause the
>> memory leak and segfault when that variable is referenced again)?
>>
>> (Un tested as of yet, just throwing it out there as it seems kind of
>> weird to overwrite the arg pointer for what seems like no reason)...
>>
>> Anthony
>>
>>
>>
>> On Mon, Feb 27, 2012 at 10:22 AM, Richard Lynch wrote:
>>> On Mon, February 27, 2012 2:31 am, Laruence wrote:
On Mon, Feb 27, 2012 at 4:00 PM, Dmitry Stogov
wrote:
> Hi Laruence,
>
> The attached patch looks wired. The patch on top of it (r323563)
> makes it
> better. However, in my opinion it fixes a common problem just in a
> single
> place. Each call to __toString() that makes "side effects" may cause
> the
> similar problem. It would be great to make a "right" fix in
> zend_std_cast_object_tostring() itself, but probably it would
> require API
Hi:
before this fix, I thought about the same idea of that.
but, you know, such change will need all exts who implmented
their own cast_object handler change there codes too.
for now, I exam the usage of std_cast_object_tostring, most of
them do the similar things like this fix to avoid this issues(like
ZEND_CAST handler).
so I think, maybe it's okey for a temporary fix :)
>>>
>>> Perhaps a better solution would be to make a NEW function that uses
>>> zval** and deprecate the old one with memory leaks.
>>>
>>> Old extensions remain functional, new extension consume less memory.
>>>
>>> (This presumes I actually understand the issue, which is questionable.)
>>>
>>> --
>>> brain cancer update:
>>> http://richardlynch.blogspot.com/search/label/brain%20tumor
>>> Donate:
>>> https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
>>>
>>>
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-CVS] Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/NEWS branches/PHP_5_3/Zend/zend_API.c trunk/NEWS trunk/Zend/zend_API.c
Sent from my iPad
在 2012-2-28，0:10，Anthony Ferrara 写道：
> Out of curiosity, why are you changing it to copy the object for the
> result of the cast operation? cast_object should init the result
> zval, so why go through the step of copying the starting object to
plz look at the final fix： r323563
thanks
> r323563
> Wouldn't it be easier just to do:
>
>if (Z_OBJ_HANDLER_PP(arg, cast_object)) {
>zval *result;
>ALLOC_ZVAL(result);
>if (Z_OBJ_HANDLER_P(*arg, cast_object)(*arg, result, type TSRMLS_CC)
> == SUCCESS) {
>zval_ptr_dtor(arg);
>*pl = Z_STRLEN_PP(result);
>*p = Z_STRVAL_PP(result);
>zval_ptr_dtor(result);
>return SUCCESS;
>}
>zval_ptr_dtor(result);
>}
>
> Keeping both completely separate, and not having the possibility of
> corrupting the arg object pointer? As it is right now (with the patch
> in the first mail), wouldn't the possibility still exist of nuking the
> arg object pointer which could be used elsewhere (and hence cause the
> memory leak and segfault when that variable is referenced again)?
>
> (Un tested as of yet, just throwing it out there as it seems kind of
> weird to overwrite the arg pointer for what seems like no reason)...
>
> Anthony
>
>
>
> On Mon, Feb 27, 2012 at 10:22 AM, Richard Lynch wrote:
>> On Mon, February 27, 2012 2:31 am, Laruence wrote:
>>> On Mon, Feb 27, 2012 at 4:00 PM, Dmitry Stogov
>>> wrote:
Hi Laruence,
The attached patch looks wired. The patch on top of it (r323563)
makes it
better. However, in my opinion it fixes a common problem just in a
single
place. Each call to __toString() that makes "side effects" may cause
the
similar problem. It would be great to make a "right" fix in
zend_std_cast_object_tostring() itself, but probably it would
require API
>>> Hi:
>>>before this fix, I thought about the same idea of that.
>>>
>>>but, you know, such change will need all exts who implmented
>>> their own cast_object handler change there codes too.
>>>
>>>for now, I exam the usage of std_cast_object_tostring, most of
>>> them do the similar things like this fix to avoid this issues(like
>>> ZEND_CAST handler).
>>>
>>>so I think, maybe it's okey for a temporary fix :)
>>
>> Perhaps a better solution would be to make a NEW function that uses
>> zval** and deprecate the old one with memory leaks.
>>
>> Old extensions remain functional, new extension consume less memory.
>>
>> (This presumes I actually understand the issue, which is questionable.)
>>
>> --
>> brain cancer update:
>> http://richardlynch.blogspot.com/search/label/brain%20tumor
>> Donate:
>> https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
>>
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-CVS] Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/NEWS branches/PHP_5_3/Zend/zend_API.c trunk/NEWS trunk/Zend/zend_API.c
Out of curiosity, why are you changing it to copy the object for the
result of the cast operation? cast_object should init the result
zval, so why go through the step of copying the starting object to it?
Wouldn't it be easier just to do:
if (Z_OBJ_HANDLER_PP(arg, cast_object)) {
zval *result;
ALLOC_ZVAL(result);
if (Z_OBJ_HANDLER_P(*arg, cast_object)(*arg, result, type
TSRMLS_CC)
== SUCCESS) {
zval_ptr_dtor(arg);
*pl = Z_STRLEN_PP(result);
*p = Z_STRVAL_PP(result);
zval_ptr_dtor(result);
return SUCCESS;
}
zval_ptr_dtor(result);
}
Keeping both completely separate, and not having the possibility of
corrupting the arg object pointer? As it is right now (with the patch
in the first mail), wouldn't the possibility still exist of nuking the
arg object pointer which could be used elsewhere (and hence cause the
memory leak and segfault when that variable is referenced again)?
(Un tested as of yet, just throwing it out there as it seems kind of
weird to overwrite the arg pointer for what seems like no reason)...
Anthony
On Mon, Feb 27, 2012 at 10:22 AM, Richard Lynch wrote:
> On Mon, February 27, 2012 2:31 am, Laruence wrote:
>> On Mon, Feb 27, 2012 at 4:00 PM, Dmitry Stogov
>> wrote:
>>> Hi Laruence,
>>>
>>> The attached patch looks wired. The patch on top of it (r323563)
>>> makes it
>>> better. However, in my opinion it fixes a common problem just in a
>>> single
>>> place. Each call to __toString() that makes "side effects" may cause
>>> the
>>> similar problem. It would be great to make a "right" fix in
>>> zend_std_cast_object_tostring() itself, but probably it would
>>> require API
>> Hi:
>> before this fix, I thought about the same idea of that.
>>
>> but, you know, such change will need all exts who implmented
>> their own cast_object handler change there codes too.
>>
>> for now, I exam the usage of std_cast_object_tostring, most of
>> them do the similar things like this fix to avoid this issues(like
>> ZEND_CAST handler).
>>
>> so I think, maybe it's okey for a temporary fix :)
>
> Perhaps a better solution would be to make a NEW function that uses
> zval** and deprecate the old one with memory leaks.
>
> Old extensions remain functional, new extension consume less memory.
>
> (This presumes I actually understand the issue, which is questionable.)
>
> --
> brain cancer update:
> http://richardlynch.blogspot.com/search/label/brain%20tumor
> Donate:
> https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-CVS] Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/NEWS branches/PHP_5_3/Zend/zend_API.c trunk/NEWS trunk/Zend/zend_API.c
On Mon, February 27, 2012 2:31 am, Laruence wrote: > On Mon, Feb 27, 2012 at 4:00 PM, Dmitry Stogov > wrote: >> Hi Laruence, >> >> The attached patch looks wired. The patch on top of it (r323563) >> makes it >> better. However, in my opinion it fixes a common problem just in a >> single >> place. Each call to __toString() that makes "side effects" may cause >> the >> similar problem. It would be great to make a "right" fix in >> zend_std_cast_object_tostring() itself, but probably it would >> require API > Hi: >before this fix, I thought about the same idea of that. > >but, you know, such change will need all exts who implmented > their own cast_object handler change there codes too. > >for now, I exam the usage of std_cast_object_tostring, most of > them do the similar things like this fix to avoid this issues(like > ZEND_CAST handler). > >so I think, maybe it's okey for a temporary fix :) Perhaps a better solution would be to make a NEW function that uses zval** and deprecate the old one with memory leaks. Old extensions remain functional, new extension consume less memory. (This presumes I actually understand the issue, which is questionable.) -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-CVS] Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_4/NEWSbranches/PHP_5_4/ext/session/config.m4 branches/PHP_5_4/ext/session/config.w32branches/PHP_5_4/ext/session/mod_user.c bran
no problem, I just mentioned because it is easier to remember, and it should take care of the similar problems. On Wed, Sep 14, 2011 at 9:08 AM, Christian Stocker wrote: > > > On 14.09.11 09:00, Ferenc Kovacs wrote: >> ./vcsclean && ./buildconf --force > > ok, that helped. Thanks a lot and I should have known that > > chregu > >> >> On Wed, Sep 14, 2011 at 8:07 AM, Laruence wrote: >>> Hi, >>> FYI, you might should delete the autom4te.cache folder too :-) >>> >>> thanks >>> >>> 2011/9/14 Christian Stocker : Hi I still have this. even after re-running buildconf (and deleting configure before) On OS X and x86_64 Linux chregu On 14.09.11 05:31, Laruence wrote: > Hi: > after I re-run buildconf, error has gone > > sorry for mis-report. > > thanks > > 2011/9/14 Laruence : >> Hi: >> trunk build broken: >> ext/session/session.o(.rodata+0x24a8): undefined reference to >> `zim_SessionHandler_open' >> ext/session/session.o(.rodata+0x24c8): undefined reference to >> `zim_SessionHandler_close' >> ext/session/session.o(.rodata+0x24e8): undefined reference to >> `zim_SessionHandler_read' >> ext/session/session.o(.rodata+0x2508): undefined reference to >> `zim_SessionHandler_write' >> ext/session/session.o(.rodata+0x2528): undefined reference to >> `zim_SessionHandler_destroy' >> ext/session/session.o(.rodata+0x2548): undefined reference to >> `zim_SessionHandler_gc' >> collect2: ld returned 1 exit status >> make: *** [sapi/cli/php] Error 1 >> make: *** Waiting for unfinished jobs >> ext/session/session.o(.rodata+0x24a8): undefined reference to >> `zim_SessionHandler_open' >> ext/session/session.o(.rodata+0x24c8): undefined reference to >> `zim_SessionHandler_close' >> ext/session/session.o(.rodata+0x24e8): undefined reference to >> `zim_SessionHandler_read' >> ext/session/session.o(.rodata+0x2508): undefined reference to >> `zim_SessionHandler_write' >> ext/session/session.o(.rodata+0x2528): undefined reference to >> `zim_SessionHandler_destroy' >> ext/session/session.o(.rodata+0x2548): undefined reference to >> `zim_SessionHandler_gc' >> >> thanks >> >> 2011/9/14 Arpad Ray : >>> arpad Tue, 13 Sep 2011 22:28:15 + >>> >>> Revision: http://svn.php.net/viewvc?view=revision&revision=316688 >>> >>> Log: >>> Implement object-oriented session handlers >>> (https://wiki.php.net/rfc/session-oo) >>> >>> Changed paths: >>> U php/php-src/branches/PHP_5_4/NEWS >>> U php/php-src/branches/PHP_5_4/ext/session/config.m4 >>> U php/php-src/branches/PHP_5_4/ext/session/config.w32 >>> U php/php-src/branches/PHP_5_4/ext/session/mod_user.c >>> A php/php-src/branches/PHP_5_4/ext/session/mod_user_class.c >>> U php/php-src/branches/PHP_5_4/ext/session/package.xml >>> U php/php-src/branches/PHP_5_4/ext/session/php_session.h >>> U php/php-src/branches/PHP_5_4/ext/session/session.c >>> A >>> php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_001.phpt >>> A >>> php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_002.phpt >>> A >>> php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_003.phpt >>> A >>> php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_004.phpt >>> A >>> php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_005.phpt >>> A >>> php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_006.phpt >>> A >>> php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_007.phpt >>> A >>> php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_008.phpt >>> A >>> php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_009.phpt >>> A >>> php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_010.phpt >>> A >>> php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_011.phpt >>> A >>> php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_012.phpt >>> A >>> php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_013.phpt >>> A >>> php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_014.phpt >>> U php/php-src/branches/PHP_5_4/ext/standard/basic_functions.c >>> U php/php-src/branches/PHP_5_4/ext/standard/basic_functions.h >>> U php/php-src/trunk/ext/session/config.m4 >>> U php/php-src/trunk/ext/session/config.w32 >>> U p
[PHP-CVS] Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_4/NEWSbranches/PHP_5_4/ext/session/config.m4 branches/PHP_5_4/ext/session/config.w32branches/PHP_5_4/ext/session/mod_user.c bran
On 14.09.11 09:00, Ferenc Kovacs wrote: > ./vcsclean && ./buildconf --force ok, that helped. Thanks a lot and I should have known that chregu > > On Wed, Sep 14, 2011 at 8:07 AM, Laruence wrote: >> Hi, >> FYI, you might should delete the autom4te.cache folder too :-) >> >> thanks >> >> 2011/9/14 Christian Stocker : >>> Hi >>> >>> I still have this. even after re-running buildconf (and deleting >>> configure before) >>> >>> On OS X and x86_64 Linux >>> >>> chregu >>> >>> On 14.09.11 05:31, Laruence wrote: Hi: after I re-run buildconf, error has gone sorry for mis-report. thanks 2011/9/14 Laruence : > Hi: >trunk build broken: >ext/session/session.o(.rodata+0x24a8): undefined reference to > `zim_SessionHandler_open' > ext/session/session.o(.rodata+0x24c8): undefined reference to > `zim_SessionHandler_close' > ext/session/session.o(.rodata+0x24e8): undefined reference to > `zim_SessionHandler_read' > ext/session/session.o(.rodata+0x2508): undefined reference to > `zim_SessionHandler_write' > ext/session/session.o(.rodata+0x2528): undefined reference to > `zim_SessionHandler_destroy' > ext/session/session.o(.rodata+0x2548): undefined reference to > `zim_SessionHandler_gc' > collect2: ld returned 1 exit status > make: *** [sapi/cli/php] Error 1 > make: *** Waiting for unfinished jobs > ext/session/session.o(.rodata+0x24a8): undefined reference to > `zim_SessionHandler_open' > ext/session/session.o(.rodata+0x24c8): undefined reference to > `zim_SessionHandler_close' > ext/session/session.o(.rodata+0x24e8): undefined reference to > `zim_SessionHandler_read' > ext/session/session.o(.rodata+0x2508): undefined reference to > `zim_SessionHandler_write' > ext/session/session.o(.rodata+0x2528): undefined reference to > `zim_SessionHandler_destroy' > ext/session/session.o(.rodata+0x2548): undefined reference to > `zim_SessionHandler_gc' > > thanks > > 2011/9/14 Arpad Ray : >> arpadTue, 13 Sep 2011 22:28:15 + >> >> Revision: http://svn.php.net/viewvc?view=revision&revision=316688 >> >> Log: >> Implement object-oriented session handlers >> (https://wiki.php.net/rfc/session-oo) >> >> Changed paths: >>U php/php-src/branches/PHP_5_4/NEWS >>U php/php-src/branches/PHP_5_4/ext/session/config.m4 >>U php/php-src/branches/PHP_5_4/ext/session/config.w32 >>U php/php-src/branches/PHP_5_4/ext/session/mod_user.c >>A php/php-src/branches/PHP_5_4/ext/session/mod_user_class.c >>U php/php-src/branches/PHP_5_4/ext/session/package.xml >>U php/php-src/branches/PHP_5_4/ext/session/php_session.h >>U php/php-src/branches/PHP_5_4/ext/session/session.c >>A >> php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_001.phpt >>A >> php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_002.phpt >>A >> php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_003.phpt >>A >> php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_004.phpt >>A >> php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_005.phpt >>A >> php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_006.phpt >>A >> php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_007.phpt >>A >> php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_008.phpt >>A >> php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_009.phpt >>A >> php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_010.phpt >>A >> php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_011.phpt >>A >> php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_012.phpt >>A >> php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_013.phpt >>A >> php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_014.phpt >>U php/php-src/branches/PHP_5_4/ext/standard/basic_functions.c >>U php/php-src/branches/PHP_5_4/ext/standard/basic_functions.h >>U php/php-src/trunk/ext/session/config.m4 >>U php/php-src/trunk/ext/session/config.w32 >>U php/php-src/trunk/ext/session/mod_user.c >>A php/php-src/trunk/ext/session/mod_user_class.c >>U php/php-src/trunk/ext/session/package.xml >>U php/php-src/trunk/ext/session/php_session.h >>U php/php-src/trunk/ext/session/session.c >>A >> p
[PHP-CVS] Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_4/NEWSbranches/PHP_5_4/ext/session/config.m4 branches/PHP_5_4/ext/session/config.w32branches/PHP_5_4/ext/session/mod_user.c bran
./vcsclean && ./buildconf --force On Wed, Sep 14, 2011 at 8:07 AM, Laruence wrote: > Hi, > FYI, you might should delete the autom4te.cache folder too :-) > > thanks > > 2011/9/14 Christian Stocker : >> Hi >> >> I still have this. even after re-running buildconf (and deleting >> configure before) >> >> On OS X and x86_64 Linux >> >> chregu >> >> On 14.09.11 05:31, Laruence wrote: >>> Hi: >>> after I re-run buildconf, error has gone >>> >>> sorry for mis-report. >>> >>> thanks >>> >>> 2011/9/14 Laruence : Hi: trunk build broken: ext/session/session.o(.rodata+0x24a8): undefined reference to `zim_SessionHandler_open' ext/session/session.o(.rodata+0x24c8): undefined reference to `zim_SessionHandler_close' ext/session/session.o(.rodata+0x24e8): undefined reference to `zim_SessionHandler_read' ext/session/session.o(.rodata+0x2508): undefined reference to `zim_SessionHandler_write' ext/session/session.o(.rodata+0x2528): undefined reference to `zim_SessionHandler_destroy' ext/session/session.o(.rodata+0x2548): undefined reference to `zim_SessionHandler_gc' collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 make: *** Waiting for unfinished jobs ext/session/session.o(.rodata+0x24a8): undefined reference to `zim_SessionHandler_open' ext/session/session.o(.rodata+0x24c8): undefined reference to `zim_SessionHandler_close' ext/session/session.o(.rodata+0x24e8): undefined reference to `zim_SessionHandler_read' ext/session/session.o(.rodata+0x2508): undefined reference to `zim_SessionHandler_write' ext/session/session.o(.rodata+0x2528): undefined reference to `zim_SessionHandler_destroy' ext/session/session.o(.rodata+0x2548): undefined reference to `zim_SessionHandler_gc' thanks 2011/9/14 Arpad Ray : > arpad Tue, 13 Sep 2011 22:28:15 + > > Revision: http://svn.php.net/viewvc?view=revision&revision=316688 > > Log: > Implement object-oriented session handlers > (https://wiki.php.net/rfc/session-oo) > > Changed paths: > U php/php-src/branches/PHP_5_4/NEWS > U php/php-src/branches/PHP_5_4/ext/session/config.m4 > U php/php-src/branches/PHP_5_4/ext/session/config.w32 > U php/php-src/branches/PHP_5_4/ext/session/mod_user.c > A php/php-src/branches/PHP_5_4/ext/session/mod_user_class.c > U php/php-src/branches/PHP_5_4/ext/session/package.xml > U php/php-src/branches/PHP_5_4/ext/session/php_session.h > U php/php-src/branches/PHP_5_4/ext/session/session.c > A > php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_001.phpt > A > php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_002.phpt > A > php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_003.phpt > A > php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_004.phpt > A > php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_005.phpt > A > php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_006.phpt > A > php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_007.phpt > A > php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_008.phpt > A > php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_009.phpt > A > php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_010.phpt > A > php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_011.phpt > A > php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_012.phpt > A > php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_013.phpt > A > php/php-src/branches/PHP_5_4/ext/session/tests/session_set_save_handler_class_014.phpt > U php/php-src/branches/PHP_5_4/ext/standard/basic_functions.c > U php/php-src/branches/PHP_5_4/ext/standard/basic_functions.h > U php/php-src/trunk/ext/session/config.m4 > U php/php-src/trunk/ext/session/config.w32 > U php/php-src/trunk/ext/session/mod_user.c > A php/php-src/trunk/ext/session/mod_user_class.c > U php/php-src/trunk/ext/session/package.xml > U php/php-src/trunk/ext/session/php_session.h > U php/php-src/trunk/ext/session/session.c > A > php/php-src/trunk/ext/session/tests/session_set_save_handler_class_001.phpt > A > php/php-src/trunk/ext/session/tests/session_set_save_handler_class_002.phpt > A > php/php-src/trunk/ext/session/tests/ses
[PHP-CVS] Re: [PHP-DEV] Re: [PHP-CVS] Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/NEWS branches/PHP_5_3/Zend/tests/bug53727.phpt branches/PHP_5_3/Zend/tests/is_a.phpt branches/PHP_
Hi Folks: On Thu, Jul 07, 2011 at 02:20:50PM -0700, Stas Malyshev wrote: > > In fact, I'm not sure why would we need such warning at all. Unknown > class - return false, who cares? +1 Thanks, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/NEWS branches/PHP_5_3/Zend/tests/bug53727.phpt branches/PHP_5_3/Zend/tests/is_a.phpt branches/PHP_5_3/Zend/zend_builtin_fu
Hi! On 7/7/11 2:08 PM, Johannes Schlüter wrote: On Thu, 2011-07-07 at 20:27 +0200, Pierre Joye wrote: what kind of troubles do they see? https://pear.php.net/bugs/bug.php?id=18656 Even if the Warning is good it's questionable for 5.3, especially during RC. Yes, I had problem with it too in couple of cases, breaks some unit tests. In fact, I'm not sure why would we need such warning at all. Unknown class - return false, who cares? PHP is way too talkative anyway, which leads to a tons of boilerplate code that serve no useful purpose but to shut it up. But leaving that aside, I think 5.3 shouldn't have this additional warning this late. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-CVS] Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/NEWS branches/PHP_5_3/Zend/tests/bug53727.phpt branches/PHP_5_3/Zend/tests/is_a.phpt branches/PHP_5_3/Zend/zend_builtin_functi
On Thu, 2011-07-07 at 20:27 +0200, Pierre Joye wrote: > what kind of troubles do they see? https://pear.php.net/bugs/bug.php?id=18656 Even if the Warning is good it's questionable for 5.3, especially during RC. (note that warnings not only cause the error being reported, which can be switched off and fill logfiles but also triggers error handlers which won't expect this ...) johannes > 2011/7/7 Johannes Schlüter : > > Hi, > > > > I was told (didn't verify) that this causes lots of trouble with PEAR > > and other applications. We're in final RC phase of 5.3.7. I don't think > > it is critical for 5.3.7 and I wonder whether we need it for 5.3 at all. > > > > johannes > > > > On Mon, 2011-07-04 at 14:55 +, Dmitry Stogov wrote: > >> dmitry Mon, 04 Jul 2011 14:55:39 + > >> > >> Revision: http://svn.php.net/viewvc?view=revision&revision=312904 > >> > >> Log: > >> Fixed bug #53727 (Inconsistent behavior of is_subclass_of with interfaces) > >> > >> Bug: https://bugs.php.net/53727 (Assigned) Inconsistent behavior of > >> is_subclass_of with interfaces > >> > >> Changed paths: > >> U php/php-src/branches/PHP_5_3/NEWS > >> A php/php-src/branches/PHP_5_3/Zend/tests/bug53727.phpt > >> U php/php-src/branches/PHP_5_3/Zend/tests/is_a.phpt > >> U php/php-src/branches/PHP_5_3/Zend/zend_builtin_functions.c > >> U > >> php/php-src/branches/PHP_5_3/ext/standard/tests/class_object/is_a_variation_001.phpt > >> A php/php-src/branches/PHP_5_4/Zend/tests/bug53727.phpt > >> U php/php-src/branches/PHP_5_4/Zend/tests/is_a.phpt > >> U php/php-src/branches/PHP_5_4/Zend/zend_builtin_functions.c > >> U > >> php/php-src/branches/PHP_5_4/ext/standard/tests/class_object/is_a_variation_001.phpt > >> A php/php-src/trunk/Zend/tests/bug53727.phpt > >> U php/php-src/trunk/Zend/tests/is_a.phpt > >> U php/php-src/trunk/Zend/zend_builtin_functions.c > >> U > >> php/php-src/trunk/ext/standard/tests/class_object/is_a_variation_001.phpt > >> > >> -- > >> PHP CVS Mailing List (http://www.php.net/) > >> To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-CVS] Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/NEWS branches/PHP_5_3/Zend/tests/bug53727.phpt branches/PHP_5_3/Zend/tests/is_a.phpt branches/PHP_5_3/Zend/zend_builtin_functi
what kind of troubles do they see? 2011/7/7 Johannes Schlüter : > Hi, > > I was told (didn't verify) that this causes lots of trouble with PEAR > and other applications. We're in final RC phase of 5.3.7. I don't think > it is critical for 5.3.7 and I wonder whether we need it for 5.3 at all. > > johannes > > On Mon, 2011-07-04 at 14:55 +, Dmitry Stogov wrote: >> dmitry Mon, 04 Jul 2011 14:55:39 + >> >> Revision: http://svn.php.net/viewvc?view=revision&revision=312904 >> >> Log: >> Fixed bug #53727 (Inconsistent behavior of is_subclass_of with interfaces) >> >> Bug: https://bugs.php.net/53727 (Assigned) Inconsistent behavior of >> is_subclass_of with interfaces >> >> Changed paths: >> U php/php-src/branches/PHP_5_3/NEWS >> A php/php-src/branches/PHP_5_3/Zend/tests/bug53727.phpt >> U php/php-src/branches/PHP_5_3/Zend/tests/is_a.phpt >> U php/php-src/branches/PHP_5_3/Zend/zend_builtin_functions.c >> U >> php/php-src/branches/PHP_5_3/ext/standard/tests/class_object/is_a_variation_001.phpt >> A php/php-src/branches/PHP_5_4/Zend/tests/bug53727.phpt >> U php/php-src/branches/PHP_5_4/Zend/tests/is_a.phpt >> U php/php-src/branches/PHP_5_4/Zend/zend_builtin_functions.c >> U >> php/php-src/branches/PHP_5_4/ext/standard/tests/class_object/is_a_variation_001.phpt >> A php/php-src/trunk/Zend/tests/bug53727.phpt >> U php/php-src/trunk/Zend/tests/is_a.phpt >> U php/php-src/trunk/Zend/zend_builtin_functions.c >> U >> php/php-src/trunk/ext/standard/tests/class_object/is_a_variation_001.phpt >> >> -- >> PHP CVS Mailing List (http://www.php.net/) >> To unsubscribe, visit: http://www.php.net/unsub.php > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-CVS] Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_2/Zend/tests/bug51421.phpt branches/PHP_5_2/Zend/zend_compile.c branches/PHP_5_3/Zend/tests/bug51421.phpt branches/PHP_5_3
Hi,
On Mon, Jun 28, 2010 at 20:17, Stas Malyshev wrote:
> Hi!
>
> 1) arguments can be gathered dynamically in the function, using
>> func_get_args. For that reason, PHP gracefully allow a call with too many
>> arguments.
>>
>
> Isn't it the case today?
>
It's the case at the time of the calls. But not when overriding a method:
class A { public function foo($a) { } }
class B extends A { public function foo() {} }
is considered invalid, but $obj->foo($arg); would be perfectly valid for
both objects.
> Maybe also we can add some syntax like:
> function foo($a, $b, ...) - where ... means "I'll deal with those arguments
> myself, ignore any compatibility checks" so if the prototype is
> foo($a,$b,$c) $a and $b would be checked but not $c and the function is
> considered to have enough args.
>
I'd find that syntax pretty explicit and easy to understand, it wouldn't
break any BC.
>
> 2) a child method should be allowed to define type hints in a
>> contra-variant
>> manner (currently, it's invariant)
>>
>
> This needs to be fixed.
>
> 3) a child method should be allowed to return a ref even if the parent
>> method is not defined to do so. (returning a ref is an additional
>> constraint, and following co-variance of return values, it should be
>> allowed). The basic example of this annoyance is: abstract class A
>> implements ArrayAcces { public function&__offsetGet($name) { ... } }
>>
>
> This needs to be fixed too.
>
> 4) all in all: it shouldn't throw a fatal error, those are not critical
>> situations for the engine.
>>
>
> I'd say in general OO part of PHP seems to be much more strict and
> Java-like than the rest. I'm not sure it's good. I'd demote all situations
> where the engine has a way to proceed to at least warning level.
>
I don't believe that any of those checks causes difficulty for the engine,
especially considering that internal classes can pretty much to what they
want anyway.
>
> I'd like to propose to relax such checks, by either allowing more (e.g. 1,
>> 2
>> and 3) which can be painful and complicated, or simply removing those
>> checks.
>>
>
> I think we shouldn't remove them - we should fix them. It doesn't seem to
> be too hard, IMHO.
>
Enforcing contra-variance can become a tad bit tricky when it comes to:
1) argument vs no argument
2) argument with/without null as default value
3) by ref or not (with/without default values)
We should probably specify it formally in which case a prototype is
accepted, and then see what needs to be fixed.
Also, checking for subtyping in PHP is O(n) which is "slow", but I don't
believe it's a concern big enough to change the way we implement
"instanceof".
Best,
--
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
--
Etienne Kneuss
http://www.colder.ch
Re: [PHP-CVS] Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_2/Zend/tests/bug51421.phpt branches/PHP_5_2/Zend/zend_compile.c branches/PHP_5_3/Zend/tests/bug51421.phpt branches/PHP_5_3
Hi!
1) arguments can be gathered dynamically in the function, using
func_get_args. For that reason, PHP gracefully allow a call with too many
arguments.
Isn't it the case today?
Maybe also we can add some syntax like:
function foo($a, $b, ...) - where ... means "I'll deal with those
arguments myself, ignore any compatibility checks" so if the prototype
is foo($a,$b,$c) $a and $b would be checked but not $c and the function
is considered to have enough args.
2) a child method should be allowed to define type hints in a contra-variant
manner (currently, it's invariant)
This needs to be fixed.
3) a child method should be allowed to return a ref even if the parent
method is not defined to do so. (returning a ref is an additional
constraint, and following co-variance of return values, it should be
allowed). The basic example of this annoyance is: abstract class A
implements ArrayAcces { public function&__offsetGet($name) { ... } }
This needs to be fixed too.
4) all in all: it shouldn't throw a fatal error, those are not critical
situations for the engine.
I'd say in general OO part of PHP seems to be much more strict and
Java-like than the rest. I'm not sure it's good. I'd demote all
situations where the engine has a way to proceed to at least warning level.
I'd like to propose to relax such checks, by either allowing more (e.g. 1, 2
and 3) which can be painful and complicated, or simply removing those
checks.
I think we shouldn't remove them - we should fix them. It doesn't seem
to be too hard, IMHO.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-CVS] Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_2/Zend/tests/bug51421.phpt branches/PHP_5_2/Zend/zend_compile.c branches/PHP_5_3/Zend/tests/bug51421.phpt branches/PHP_5_3/Zen
Hi,
2010/6/28 Johannes Schlüter
> Hi,
>
> On Sat, 2010-06-26 at 22:05 +, Felipe Pena wrote:
> > felipe Sat, 26 Jun 2010 22:05:13 +
> >
> > Revision: http://svn.php.net/viewvc?view=revision&revision=300770
> >
> > Log:
> > - Fixed bug #51421 (Abstract __construct constructor argument list not
> enforced)
> >
> > Bug: http://bugs.php.net/51421 (Closed) Abstract __construct constructor
> argument list not enforced
>
> Won't this break compatibility?
>
> I'd say the change is logically correct but not sure we should break BC
> there during RC.
>
At the risk of starting some political debate, I believe that the current
state of prototype checks make close to no sense in PHP, for 4 reasons:
1) arguments can be gathered dynamically in the function, using
func_get_args. For that reason, PHP gracefully allow a call with too many
arguments.
2) a child method should be allowed to define type hints in a contra-variant
manner (currently, it's invariant)
3) a child method should be allowed to return a ref even if the parent
method is not defined to do so. (returning a ref is an additional
constraint, and following co-variance of return values, it should be
allowed). The basic example of this annoyance is: abstract class A
implements ArrayAcces { public function &__offsetGet($name) { ... } }
4) all in all: it shouldn't throw a fatal error, those are not critical
situations for the engine.
I'd like to propose to relax such checks, by either allowing more (e.g. 1, 2
and 3) which can be painful and complicated, or simply removing those
checks.
Best,
>
> johannes
>
> > Changed paths:
> > A php/php-src/branches/PHP_5_2/Zend/tests/bug51421.phpt
> > U php/php-src/branches/PHP_5_2/Zend/zend_compile.c
> > A php/php-src/branches/PHP_5_3/Zend/tests/bug51421.phpt
> > U php/php-src/branches/PHP_5_3/Zend/zend_compile.c
> > A php/php-src/trunk/Zend/tests/bug51421.phpt
> > U php/php-src/trunk/Zend/zend_compile.c
> >
> > Added: php/php-src/branches/PHP_5_2/Zend/tests/bug51421.phpt
> > ===
> > --- php/php-src/branches/PHP_5_2/Zend/tests/bug51421.phpt
> (rev 0)
> > +++ php/php-src/branches/PHP_5_2/Zend/tests/bug51421.phpt 2010-06-26
> 22:05:13 UTC (rev 300770)
> > @@ -0,0 +1,18 @@
> > +--TEST--
> > +Bug #51421 (Abstract __construct constructor argument list not enforced)
> > +--FILE--
> > + > +
> > +class ExampleClass {}
> > +
> > +abstract class TestInterface {
> > + abstract public function __construct(ExampleClass $var);
> > +}
> > +
> > +class Test extends TestInterface {
> > + public function __construct() {}
> > +}
> > +
> > +?>
> > +--EXPECTF--
> > +Fatal error: Declaration of Test::__construct() must be compatible with
> that of TestInterface::__construct() in %s on line %d
> >
> >
> > Property changes on:
> php/php-src/branches/PHP_5_2/Zend/tests/bug51421.phpt
> > ___
> > Added: svn:keywords
> >+ Id Rev Revision
> > Added: svn:eol-style
> >+ native
> >
> > Modified: php/php-src/branches/PHP_5_2/Zend/zend_compile.c
> > ===
> > --- php/php-src/branches/PHP_5_2/Zend/zend_compile.c 2010-06-26 21:29:56
> UTC (rev 300769)
> > +++ php/php-src/branches/PHP_5_2/Zend/zend_compile.c 2010-06-26 22:05:13
> UTC (rev 300770)
> > @@ -2009,13 +2009,20 @@
> > {
> > zend_uint i;
> >
> > - /* If it's a user function then arg_info == NULL means we don't
> have any parameters but we still need to do the arg number checks. We are
> only willing to ignore this for internal functions because extensions don't
> always define arg_info. */
> > + /* If it's a user function then arg_info == NULL means we don't
> have any parameters but
> > + * we still need to do the arg number checks. We are only willing
> to ignore this for internal
> > + * functions because extensions don't always define arg_info.
> > + */
> > if (!proto || (!proto->common.arg_info && proto->common.type !=
> ZEND_USER_FUNCTION)) {
> > return 1;
> > }
> >
> > - /* Checks for constructors only if they are declared in an
> interface */
> > - if ((fe->common.fn_flags & ZEND_ACC_CTOR) &&
> !(proto->common.scope->ce_flags & ZEND_ACC_INTERFACE)) {
> > + /* Checks for constructors only if they are declared in an
> interface,
> > + * or explicitly marked as abstract
> > + */
> > + if ((fe->common.fn_flags & ZEND_ACC_CTOR)
> > + && ((proto->common.scope->ce_flags & ZEND_ACC_INTERFACE) ==
> 0
> > + && (proto->common.fn_flags & ZEND_ACC_ABSTRACT) ==
> 0)) {
> > return 1;
> > }
> >
> >
> > Added: php/php-src/branches/PHP_5_3/Zend/tests/bug51421.phpt
> > ===
> > --- php/php-src/branches/PHP_5_3/Zend/t
[PHP-CVS] Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/NEWS branches/PHP_5_3/ext/pdo/pdo_dbh.c branches/PHP_5_3/ext/pdo/php_pdo_driver.h branches/PHP_5_3/ext/pdo_pgsql/pdo_pgsql.c
> Here you are changing a structure which is allocated and initialized in > a driver and then read from the PDO core. PDO core will therefore read > invalid memory when a driver compiled against 5.3.2 is used in 5.3.3 > while we usually guarantee binary compatibility in bug fix releases. > > This for instance affects distributors or MSFT's sqlsrv driver. Not only that, but why in the world did you commit that to 5.3? 5.3 is bug fix only, committing something like in trunk is bad enough, but adding that in 5.3 is simply not correct. Please revert. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-CVS] Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/branches/
where did that mail come from? imho it should have been addressed to the mailing list directly. I agree that he was short-tempered, but I think that the progress worth it. Tyrael On Fri, Mar 12, 2010 at 3:43 PM, Pierre Joye wrote: > On Fri, Mar 12, 2010 at 3:38 PM, Lukas Kahwe Smith > wrote: > >> imho jani's commit access should be revoked until we have sorted out our >> release plan for the future, because he has shown that he has no patience to >> respect other people's opinions and so we can alleviate him of doing stupid >> things to release his anxiety. but i guess i am just being a rule loving >> german here .. or am i just the only one with enough guts to say this? > > +1, until everything is in place. > > Cheers, > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
