Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:66578 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 7632 invoked from network); 11 Mar 2013 08:50:22 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Mar 2013 08:50:22 -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:50487] helo=h1123647.serverkompetenz.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id CC/E4-09030-7CA9D315 for ; Mon, 11 Mar 2013 03:50:20 -0500 Received: by h1123647.serverkompetenz.net (Postfix, from userid 33) id C65C49145B3; Mon, 11 Mar 2013 09:50:12 +0100 (CET) Received: from 178.7.120.140 (SquirrelMail authenticated user anatol@belski.net) by webmail.klapt.com with HTTP; Mon, 11 Mar 2013 09:50:12 +0100 Message-ID: <00824f21b8abd44ee577bdde7df711d4.squirrel@webmail.klapt.com> In-Reply-To: References: <1362869409.3221.77.camel@ghost> Date: Mon, 11 Mar 2013 09:50:12 +0100 To: "Derick Rethans" Cc: "Gustavo Lopes" , 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] Fix for bug #63437 From: ab@php.net ("Anatol Belski") libgmp was just the first shot as it has functions to convert from arbitrary binary data to string and vice versa, mpz_import and mpz_export. That's what should work fine across platforms. Looking at the type definitions here http://lxr.php.net/xref/PHP_5_5/ext/date/lib/timelib_structs.h#70 i wouldn't exclude possible platform issues. Implementing that manually is a tricky job, could be done probably with more homework :) What is the way you had in the mind to achieve the string<->integer conversions? Regards Anatol On Sun, March 10, 2013 23:11, Derick Rethans wrote: > On Sat, 9 Mar 2013, Anatol Belski wrote: > > >> 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)? > > Why do you need libgmp for that‽ > > > cheers, Derick