Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:66691 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 58690 invoked from network); 18 Mar 2013 18:43:48 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Mar 2013 18:43:48 -0000 Authentication-Results: pb1.pair.com smtp.mail=ab@php.net; spf=unknown; sender-id=unknown Authentication-Results: pb1.pair.com header.from=ab@php.net; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.73.107 as permitted sender) X-PHP-List-Original-Sender: ab@php.net X-Host-Fingerprint: 85.214.73.107 klapt.com Received: from [85.214.73.107] ([85.214.73.107:36706] helo=h1123647.serverkompetenz.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 96/7A-31424-06067415 for ; Mon, 18 Mar 2013 13:43:48 -0500 Received: by h1123647.serverkompetenz.net (Postfix, from userid 33) id 5A5A591459E; Mon, 18 Mar 2013 19:43:41 +0100 (CET) Received: from 188.110.166.222 (SquirrelMail authenticated user anatol@belski.net) by webmail.klapt.com with HTTP; Mon, 18 Mar 2013 19:43:41 +0100 Message-ID: <9159f3729a9d1f89e41e5ab62fc19a5b.squirrel@webmail.klapt.com> In-Reply-To: References: Date: Mon, 18 Mar 2013 19:43:41 +0100 To: =?UTF-8?Q?=22Johannes_Schl=C3=BCter=22?= Cc: ab@php.net, "Stas Malyshev" , "David Soria Parra" , internals@lists.php.net Reply-To: ab@php.net User-Agent: SquirrelMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] Merge #62852 and #53437 into 5.3 and 5.4 From: ab@php.net ("Anatol Belski") 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 On Mon, March 18, 2013 18:03, Johannes Schlüter wrote: > 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 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 >> >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> >