|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2012-02-10 09:20 UTC] su dot hang at yahoo dot com
Description: ------------ related bug: https://bugs.php.net/bug.php?id=39588 if unpacking from a binary string ending with any number of "\0"'s, and the unpack string length is given, the resulted string does not have the right length. for example, unpack("a5", "str\0") should result in a 5-byte-long string, but it returns a 3-byte-long instead. Test script: --------------- <?php $var = "str"; $packed = pack("a5", $var); // 5 bytes long NULL-padded string var_dump(unpack("a5", $packed)); Expected result: ---------------- array(1) { [1]=> string(5) "str\0\0" } Actual result: -------------- array(1) { [1]=> string(3) "str" } PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Fri Oct 24 22:00:02 2025 UTC |
I don't see anything wrong here. unpack("a5", "foo\0\0") removes the NULL padding from the input string. The 5 specifies only the size of the input to consume: php > var_dump(unpack("a5", "foo\0")); PHP Warning: unpack(): Type a: not enough input, need 5, have 4 in php shell code on line 1sorry, please use the test script instead of the subject. It is a bug because it is against the spec that "a" is an arbitrary binary string. If specified length is 5 then it should be null-padded at the end, rather than being truncated. try unpack('a5', "\x12\x34\x00\x56\x00"). at least, to be consistent, the result string should terminate at the first "\0", instead of the trailing one. btw, perl is handling it correctly.yes, that's right. "a", as in the spec, represents arbitrary binary string, with null-padding. so, if the specified unpack length is fixed, such as a constant number (like in "unpack('a10')"), then the unpacked string from "a" should have that length (unless, of course, if the input is insufficient). since "a" is arbitrary binary string, if it has several "\0"s at the end, php should not remove them as if it was a regular null-terminated string.