Hi, On Sat, 2013-03-09 at 21:57 +0100, Gustavo Lopes wrote: > On Sat, 09 Mar 2013 21:36:41 +0100, Derick Rethans <der...@php.net> 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 > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
