Re: com php-src: Add optional second arg to unserialize(): ext/standard/basic_functions.c ext/standard/tests/serialize/serialization_error_001.phpt
ext/standard/tests/serialize/unserialize_consumed.phpt ext/standard/var.c

On Sun, Apr 13, 2014 at 2:52 AM, Ferenc Kovacs <tyra3l@gmail.com> wrote: > > > > On Fri, Jul 5, 2013 at 5:43 AM, Stas Malyshev <smalyshev@sugarcrm.com> > wrote: > >> Hi! >> >> > Please add a note to UPGRADING as well. >> > >> > Thanks! >> >> I understand UPGRADING still not updated? Could you please update it? >> >> > hi, > > When fixing https://bugs.php.net/bug.php?id=66568 today I found > out that > this is still not mentioned in NEWS or UPDATING. > Maybe our mails not getting through to Sara? Let's see if using her other > address help. > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu > managed to reach Sara through twitter( https://twitter.com/Tyr43l/status/456777526908837888), but still not done. almost commited the missing info to UPGRADING, but then I got some second thoughts. Assuming that only SplDoublyLinkedList uses this streamed serialize format and given how that class has it's own serialize/unserialize methods, I think that there is no reason to legalize the usage such strings. I think that unserialize should raise a warning when there are still unconsumed data in the string after finding the end of the serialized format, so that the user is aware that he is feeding corrupt data to the unserialize and if there are cases when we internally construct such strings we should review and either eliminate those, or introduce this format as a first-class citizen with some kind of stream wrapper or iterator, instead of providing the minimal amount of information so that somebody can parse those kind of strings by hand. what do you think? -- Ferenc Kovács @Tyr43l - http://tyrael.hu