Re: Re: #53437
| From: | Etienne Kneuss | Date: | Mon, 10 Jun 2013 12:04:19 +0000 |
| Subject: | Re: Re: #53437 | ||
| References: | 1 2 3 4 5 6 7 8 9 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-67675@lists.php.net to get a copy of this message | ||
On Mon, Jun 10, 2013 at 1:56 PM, Anatol Belski <ab@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
> > <glopes@nebm.ist.utl.pt>wrote:
> >
> >
> >> On Fri, 07 Jun 2013 14:06:11 +0200, Derick Rethans <derick@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?
> 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).
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.
Best,
--
Etienne Kneuss