Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:66571 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 96129 invoked from network); 9 Mar 2013 22:50:19 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Mar 2013 22:50:19 -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:41859] helo=h1123647.serverkompetenz.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 4F/D1-19169-7ACBB315 for ; Sat, 09 Mar 2013 17:50:18 -0500 Received: by h1123647.serverkompetenz.net (Postfix, from userid 1006) id 699A16FCBEC; Sat, 9 Mar 2013 23:50:12 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on h1123647.serverkompetenz.net X-Spam-Level: X-Spam-Status: No, score=-2.9 required=3.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.1 Received: from [192.168.178.7] (dslb-094-216-054-255.pools.arcor-ip.net [94.216.54.255]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by h1123647.serverkompetenz.net (Postfix) with ESMTPSA id 3999691459F; Sat, 9 Mar 2013 23:50:11 +0100 (CET) To: Gustavo Lopes Cc: Derick Rethans , internals@lists.php.net In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Sat, 09 Mar 2013 23:50:09 +0100 Message-ID: <1362869409.3221.77.camel@ghost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Fix for bug #63437 From: ab@php.net (Anatol Belski) Hi, On Sat, 2013-03-09 at 21:57 +0100, Gustavo Lopes wrote: > On Sat, 09 Mar 2013 21:36:41 +0100, Derick Rethans wrote: > > > On Tue, 5 Mar 2013, Anatol Belski wrote: > > > >> I've reworked the patch from > >> http://nebm.ist.utl.pt/~glopes/misc/date_period_interval_ser.diff > >> (mentioned by tony2001) for bug #63437, that seems to fix the issue. > >> That patch was ported back to 5.3 and adapted to the current 5.4+. > >> Both variants are posted to the ticket. > > > > Serializing this as a base64 encoded variant of some binary data is not > > a good thing. If you want to serialize, it needs to output the same > > thigns that allow users to create the period or interval. > > I would agree in principle, but, as I explained before, there is a > problem. The DatePeriod class has 64-bit integers in its internal > structure. The PHP integer type cannot (in general) represent that data. > So the general method of getting the object data via get_properties and > serializing (and then using __set_state to convert the array back) does > not work unless you represent those 64-bit integers with some non-integer > type and do the conversions. So base64 seems to be only the doubtful point. Thriving to fix that, what if we could bring it in dependency of libgmp to serialize and read as strings (and maybe disable serialization otherwise)? > > > I also don't think this would work for Big Endian vs Little Endian > > either. > > It does; the integers are converted to network order before being stored, > so you can share the serialized data between machines with different > endianness. > > > -- > Gustavo Lopes >