Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81942
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <54D3916F.3020606@gmail.com>
References: <CA+sv8zC==OeU9nnzxM=65A24fV+WiTdhbJgqLg-u=wVhGtL9Zw@mail.gmail.com>
	<CA+sv8zB=c5j8iZDv9mocXfkUF57U+pUJxTGyMg9mj7FAuTKyjg@mail.gmail.com>
	<54D384EC.90305@gmail.com>
	<CA+sv8zD1_g594eM00_iY_FC4_1yAL+CXBB5hxo2shNN2wwOnRQ@mail.gmail.com>
	<54D3916F.3020606@gmail.com>
Date: Thu, 5 Feb 2015 11:16:27 -0500
Message-ID: <CA+sv8zBBc0AqsiX2AZ0QmpkDosjHfFgvVHuFDCdzzBfVTpbtRg@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01494c2a4cc7a5050e59a02e
Subject: Re: [PHP-DEV] Re: Serialize generating corrupted data
From: jrbasso@gmail.com (Juan Basso)

--089e01494c2a4cc7a5050e59a02e
Content-Type: text/plain; charset=UTF-8

Thanks for changing the top posting. :)

About the solution, I like the way HHVM solves that. It is also more
consistent with the case where you add the invalid value as string on the
__sleep (ie, on http://3v4l.org/kupOg I changed the 1 from integer to
string).
If you return "N;" is hard to detected if you did serialize(null) or if it
is an error.

Should I try to solve like HHVM for the consistency with different engine
and when the invalid attribute is a string?

On Thu, Feb 5, 2015 at 10:51 AM, Rowan Collins <rowan.collins@gmail.com>
wrote:

>
>  On Thu, Feb 5, 2015 at 9:57 AM, Rowan Collins <rowan.collins@gmail.com
>> <mailto:rowan.collins@gmail.com>> wrote:
>>
>>     Playing around with existing behaviour, if you return something
>>     other than an array, you get a Notice and a serialized null ('N;')
>>     - e.g. http://3v4l.org/rm9rs
>>
>>     I think it would be reasonable for the same to happen if the array
>>     contains something other than a string, particularly given that
>>     the message would still describe the fix quite readily ( "__sleep
>>     should return an array only containing the names of
>>     instance-variables to serialize").
>>
>>     Personally, I'd have made this a Warning rather than a Notice,
>>     since it's clearly discarding data, but it should be consistent
>>     either way.
>>
>>
> Juan Basso wrote on 05/02/2015 15:20:
>
>> Rowan,
>>
>> It is happening and giving the same message, but the problem is the
>> generate value is corrupted because it generates N; without the key. Ie,
>> when you have a valid field and an invalid field it generates
>> O:1:"C":2:{s:1:"a";b:1;N;} (note that "a" is the property name, 1 is the
>> boolean value and after that it is just null without the key, causing the
>> unserialize to not be able to parse it).
>>
>> If you try to unserialize it gives you the notice "unserialize(): Error
>> at offset 25 of 26 bytes in XXX".
>>
>
> Yes, I understand the problem. What I'm saying is that if you return, say,
> a string, the result is a validly serialized Null *for the whole object*.
>
> So:
> class A { public function __sleep() { return 'bad value'; } }
> var_dump( serialize(new A) );
> // Result: string(2) "N;"
>
> I'm suggesting the same behaviour for the currently broken case, so:
>
> class B { public function __sleep() { return ['a', 42]; } }
> var_dump( serialize(new B) );
> // Current PHP, invalid: string(24) "O:1:"B":2:{s:1:"a";N;N;}"
> // Suggested, consistent with other error cases: string(2) "N;"
>
> Interestingly, HHVM generates string(29) "O:1:"B":2:{s:1:"a";N;i:42;N;}"
> and will convert the integer key to a string when it is *unserialized*.
> Adopting this as standard would be another option, I guess. See
> http://3v4l.org/S8lRA
>
> PS I fixed your top posting, because I know people don't like it. :)
>
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>

--089e01494c2a4cc7a5050e59a02e--