Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:67674 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 81056 invoked from network); 10 Jun 2013 11:56:09 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Jun 2013 11:56:09 -0000 Authentication-Results: pb1.pair.com header.from=ab@php.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=ab@php.net; spf=unknown; 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:34015] helo=h1123647.serverkompetenz.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 44/1B-30264-5DEB5B15 for ; Mon, 10 Jun 2013 07:56:08 -0400 Received: by h1123647.serverkompetenz.net (Postfix, from userid 33) id 2DD9A6BC43F; Mon, 10 Jun 2013 13:56:02 +0200 (CEST) Received: from 88.67.234.98 (SquirrelMail authenticated user anatol@belski.net) by webmail.klapt.com with HTTP; Mon, 10 Jun 2013 13:56:02 +0200 Message-ID: In-Reply-To: References: <6dd0f0c5be06dc0713890f2000a0b551.squirrel@webmail.klapt.com> Date: Mon, 10 Jun 2013 13:56:02 +0200 To: "Etienne Kneuss" Cc: "Gustavo Lopes" , "Anatol Belski" , "Derick Rethans" , =?UTF-8?Q?=22Johannes_Schl=C3=BCter=22?= , "Stas Malyshev" , "PHP internals" Reply-To: "Anatol Belski" 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] Re: #53437 From: ab@php.net ("Anatol Belski") Hi Etienne, On Mon, June 10, 2013 13:24, Etienne Kneuss wrote: > On Fri, Jun 7, 2013 at 9:27 PM, Gustavo Lopes > wrote: > > >> On Fri, 07 Jun 2013 14:06:11 +0200, Derick Rethans >> wrote: >> >> >> That's the one where conversion int <> string for serialization was >> >>>> developed. It came into 5.5 with this patches (the originally >>>> proposed patch is still attached to that ticket) >>>> >>>> http://git.php.net/?p=php-src.**git;a=commitdiff;h=** >>>> 0ee71557ffd285552659b6aa37ea23**6e3bad493f>>> -src.git;a=commitdiff;h=0ee71557ffd285552659b6aa37ea236e3bad493f> >>>> >>>> >>> >>> ["days"]=> >>> - int(3) >>> + string(1) "3" >>> >>> >>> and >>> >>> - 'days' => 0, >>> + 'days' => '0', >>> >>> >>> I see this in all test cases - this is a BC break. >>> >>> >> >> I don't think this is a BC break, or at least it's a very minor. As I >> understand it, when you read the property directly you still get an int: >> >> >> $iv = "2008-05-11T15:30:00Z/2007-03-**01T13:00:00Z"; >> $di = new DateInterval($iv); >> var_dump($di->days); //int(437) >> >> So this applies only to var_dump() output, serialization output and >> something exotic as an array cast (which anyway has its own >> peculiarities wrt the key type conversion -- or the absence of it). >> >> > So if I understand correctly var_dump now indicates a different type than > what accessing the property returns? > > Even if the change itself does not constitute a big BC break, this > behavior is confusing and seems like a big no-no to me. > As I mentioned previously, that small piece is easy fixable, though it possibly makes that place not portable between 32 and 64 bit. The main intention is to fix the unserialization crash, which IMHO interleaves this small deviation. Regards Anatol