Hi Etienne, On Mon, June 10, 2013 13:24, Etienne Kneuss wrote: > On Fri, Jun 7, 2013 at 9:27 PM, Gustavo Lopes > <glo...@nebm.ist.utl.pt>wrote: > > >> On Fri, 07 Jun 2013 14:06:11 +0200, Derick Rethans <der...@php.net> >> 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<http://git.php.net/?p=php >>>> -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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
