On Mon, June 10, 2013 14:04, Etienne Kneuss wrote: > On Mon, Jun 10, 2013 at 1:56 PM, Anatol Belski <a...@php.net> wrote: > > >> 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. > > > This is the case for most string<->int conversions, isn't it? > Exactly. The expressed concerns are about int to string part.
> >> The main >> intention is to fix the unserialization crash, which IMHO interleaves >> this small deviation. >> > > Sure, I understand the intention. It's even more a new feature than a > bug-fix at this point (as there are other ways to prevent this without > actually implementing serialization). Other ways will introduce other BC breaks as well :) The original ticket was about unserialization, so it's sensible serialization to be touched as well. > We shouldn't make the output of var_dump less consistent for something > that feels as remote as serialization/unserialization, and especially if > it is easily fixable. > The general question is - the small piece of deviation can be solved, that's may be 3% of the whole patch. So then it were ready to be backported. As despite that many hypothetical ways to fix it, the work is done on this concrete patch, which fixes the crash and is already accepted in 5.5 Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
