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: 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

« previous php.cvs (#71640) next »