On Fri, Aug 19, 2011 at 1:40 PM, Ferenc Kovacs <tyr...@gmail.com> wrote: > On Fri, Aug 19, 2011 at 2:31 PM, Arpad Ray <array...@gmail.com> wrote: >> On Fri, Aug 19, 2011 at 1:04 PM, Ferenc Kovacs <tyr...@gmail.com> wrote: >>> the downside would be that if you want to serialize/unserialize the >>> data outside of php, your implementation should take care of this >>> prefix. >>> just a wild idea, but maybe useful: >>> instead of creating a prefix, we could serialize the passed data with >>> the given(php, igbinary, etc.) handler, then wrap the whole stuff into >>> an array which holds the name of the used handler and the serialized >>> data, and serialize this array with the old(php) serialize method. >>> this way the datablob would be always a valid serialized string, and >>> would be easier to get the serialize method than with the prefixing. >> >> If my old app couldn't read some newly serialized string, I'd rather >> it failed hard than apparently succeed but have the wrong data. >> > > http://php.net/unserialize > In case the passed string is not unserializeable, FALSE is returned > and E_NOTICE is issued. > so if you unserialize from php, my suggestion would fail harder. > when you unserialize it from another mean (parsing it on your own, or > from a different language), you are right, it would produce a valid > but different result what you would expect, but this could be > documented, and I don't think that that many users do this, and maybe > they are using json/bson/igbinary already.
I'm talking about unserialize() in an old (well, current) version of PHP - if it unserializes what is apparently a valid array there would be nothing to indicate it's actually a new version which it can't read. Regards, Arpad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
