On Mon, Dec 24, 2012 at 7:13 AM, Anthony Ferrara <ircmax...@gmail.com>wrote:
> Sherif, > > > You're right. It does break BC, but this was a bug fix. >> https://bugs.php.net/bug.php?id=61038 >> >> The behavior is incorrect in that regard. >> > > However in this case that *bug* does have fairly significant BC > implications. > > In fact, how I read the specification is that the original binary format > is NULL padded, not the resulting string. Therefore, you could make the > argument that the new behavior is wrong. > > In any case, I'd suggest reverting the "bug fix" for "a", and then adding > Z which keeps the raw bytes. So that way the "bug" would be fixed by the > "Z" parameter, but "a" would still behave as it always has (allowing things > like Archive_Tar to still work properly). > > Otherwise it's a BC break that has weird implications (having different > format specifications for 5.4 and 5.5, or requiring odd things like running > trim on the output... > > My $0.02... > > Anthony > Hmm, the intent behind the fix was to get the behavior more inline with Perl's pack/unpack as in PHP they weren't behaving the same way. Apparently this has had some implications in the pecl/pear installer that I was not aware of. The BC break can be reverted of course, but the idea was to only put this patch in 5.5 because of the BC concern. Now that I recall the situation I'm not sure what the best play is here, but I'll review this again and see if this is indeed inline with the spec or not.
