Re: com php-src: Backported fix for bug #62852: NEWS ext/date/php_date.c ext/date/tests/bug62852.phpt ext/date/tests/bug62852_var2.phpt
ext/date/tests/bug62852_var3.phpt
| From: | Anatol Belski | Date: | Wed, 20 Mar 2013 09:00:22 +0000 |
| Subject: | Re: com php-src: Backported fix for bug #62852: NEWS ext/date/php_date.c ext/date/tests/bug62852.phpt ext/date/tests/bug62852_var2.phpt ext/date/tests/bug62852_var3.phpt |
||
| References: | 1 2 3 4 | Groups: | php.cvs php.internals |
| Request: | Send a blank email to php-cvs+get-71640@lists.php.net to get a copy of this message | ||
On Wed, March 20, 2013 09:05, Stas Malyshev wrote:
> Hi!
>
>
>> The issue is that a warning wouldn't destroy that object. That object
>> will occasionally segfault PHP. E_ERROR is the simplest solution which
>> doesn't change the behavior of the normal operations.
>
> Can't we just reset the object data to some known "zero" state? Having
> E_ERROR in a function that is not supposed to normally bail out is not a
> good thing - especially unserialize which may deal with external data. --
Hi,
Theoretically that's possible in DateTime while much more complicated in
DatePeriod, I wouldn't have a good conscience after that.
In the existing one there is really no intrusion into the normal datetime
functionality. Users who have used bad unserialization data or __set_state
with invalid data had a crash before. I'd apply the patch for #53437 as is
as that's the safest solution. Serialized by the usual way objects will
still work while bad data will not crash.
Regards
Anatol