Merge #62852 and #53437 into 5.3 and 5.4

Johannes,

I completely agree about the E_ERROR - in general. An error should be
recoverable as much as possible. In this concrete case as I've reworking a
patch descending from 2010 and that E_ERROR was there, I just let it go.

The situation is that doing an E_WARNING possibly leaves user with an
invalid object, which will crash on arbitrary places - in method calls,
var_dump or iterator. In 5.5 it is even possible to throw exception in
__wakeup as unserialize cares about it there. But anyway - any recoverable
error would need even more intervention into that code which could
consequently bring further behavior changes.

For #53437 as workaround maybe one could initialize the objects in
DatePeriod (as there are multiple) to some freezed value and put a
warning? That would be more permissive and bring minimal behavior changes.
I could give it a try if you mean it's acceptable. Any solution is better
than a PHP crash I mean :)

Other workaround you've possibly in mind?

Regards

Anatol

Hi,

commit f8b91d9ac (fix for #62852) looks fine to me.

Commit 0ee71 for #53437 is a bit too much for 5.3 in my opinion - what
happens if users have custom work-arounds in extended classes with custom
__wakeup or __set_State methods? Will there be a change of behavihor? I
think there should be an error message instead of a crash in 5.3. Aside
from that: I don't think that E_ERROR is a good error level for the caes,
either use E_RECOVERABLE or even just E_WARNING.

johannes

Anatol Belski ab@php.net wrote:

Hi,

#62852 and #53437 introduced fixes for the date extension crashing when
unserializing objects. They was applied to 5.5. If there are no
objections, I would backport those to 5.3 and 5.4.

Regards

Anatol