Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81939
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.177 as permitted sender)
Message-ID: <54D3916F.3020606@gmail.com>
Date: Thu, 05 Feb 2015 15:51:11 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: PHP Internals <internals@lists.php.net>
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>
In-Reply-To: <CA+sv8zD1_g594eM00_iY_FC4_1yAL+CXBB5hxo2shNN2wwOnRQ@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------010000060505020909030009"
Subject: Re: [PHP-DEV] Re: Serialize generating corrupted data
From: rowan.collins@gmail.com (Rowan Collins)

--------------010000060505020909030009
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit


> 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]

--------------010000060505020909030009--