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". On Thu, Feb 5, 2015 at 9:57 AM, Rowan Collins <rowan.coll...@gmail.com> wrote: > Juan Basso wrote on 05/02/2015 14:07: > > No one? >> >> On Mon, Feb 2, 2015 at 8:57 PM, Juan Basso <jrba...@gmail.com> wrote: >> >> Hi, >>> >>> I was testing few things today and I released one bug in the serialize >>> function. The serialize function returns a corrupted value when it is >>> serializing an object that contains a __sleep magic method and this >>> method >>> return some key that are not string. Ie: >>> >>> http://viper-7.com/EK16EV >>> >>> If the __sleep returns a string that is not a property it is fine, it >>> will >>> give the notice and the generated response is a valid serialized data (in >>> another words you can use unserialize to retrieve the object back). Ie, >>> http://viper-7.com/H9ooff >>> >>> I can try to make a patch to solve it, but before that I would like how >>> the behavior should be. Some options: >>> 1) Give the notice saying the field doesn't exist and do not include on >>> the serialized response >>> 2) Give the notice saying the field doesn't exist and convert the value >>> to >>> string (ie, on my example the int(1) would be transformed to string(1)) >>> 3) Give a warning and return false once the input from __sleep is invalid >>> 4) None of the above alternative >>> 5) Don't change it >>> >>> > 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. > > Regards, > -- > Rowan Collins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >