Re: 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 Mon, Jun 9, 2014 at 7:35 PM, Ferenc Kovacs <tyra3l@gmail.com> wrote: > On Mon, Jun 9, 2014 at 7:32 PM, Ferenc Kovacs <tyra3l@gmail.com> wrote: > >> >> >> >> 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? I cant get the point of knowing how many bytes of the serialized format the parser actually consumed. What would the user be interested in such an information for ? Julien Pauli