Edit report at https://bugs.php.net/bug.php?id=61660&edit=1
ID: 61660 Comment by: personal_homepage_tools at hochsitze dot com Reported by: krtek4+php at gmail dot com Summary: bin2hex(hex2bin($data)) != $data Status: Re-Opened Type: Bug Package: *General Issues Operating System: Debian Linux PHP Version: 5.4.1RC1 Assigned To: nikic Block user comment: N Private report: N New Comment: Just to add something constructive: obviously bin2hex must return a valid hex string, i.e. with a leading zero if the leading byte consumes less than 4 bits. *facepalm* Previous Comments: ------------------------------------------------------------------------ [2012-05-06 23:02:49] ni...@php.net @personal_homepage_tools at hochsitze dot com: I'm not sure I understand you. What's the issue with that comment? Do you disagree that a padding can be added to either sides? ------------------------------------------------------------------------ [2012-05-06 22:55:57] personal_homepage_tools at hochsitze dot com This is hardly believable. This bug is so much obvious that it hurts to read the comment "The reason is simple: A padding can be either added on the left or on the right. E.g. "af52b" could be interpreted both as "0af52b" and as "af52b0".". Anybody writing this must have failed in CS101 (hard!) - how is it working that persons who write this still obviously work for this company? I know it is hard to get something as old as PHP in a functional, future-oriented state, but as long as comments like this from official @php.net accounts are not deleted immediately this will not happen IMHO. ------------------------------------------------------------------------ [2012-04-26 21:22:12] ni...@php.net @Stas: Just to be sure we are on the same page: a) This does not break BC in any significant way. Using the function with odd length was wrong from the start. It definitely breaks less than other changes that landed to all branches, like the handling of invalid multibyte sequences in json_encode. b) If we don't change it now, it will be hard to do so later. PHP 5.4 isn't used much yet, so people didn't have much chance to misuse this function. This may change in the future. c) From hour long discussions on IRC it turns out that this is largely a documentation problem. Most people involved in the discussion thought that hex2bin() converts hexadecimal numbers to binary numbers (which is wrong). This has now be clarified in the docs: http://de3.php.net/hex2bin If you wish so, I will revert the change. But I will spend no more time discussing this. I already spent several hours in discussions about this rather unimportant issue. Thanks, Nikita. ------------------------------------------------------------------------ [2012-04-26 21:06:23] s...@php.net I do not think BC break in 5.4 is a good idea. ------------------------------------------------------------------------ [2012-04-11 06:13:50] theanomaly dot is at gmail dot com The patch currently in master still leaves a remanent problem. First, var_dump(hex2bin('')) still returns string(0) "". Whether or not this is acceptable is arguable. Since 0x00 is null, but an empty string isn't really null. For example: var_dump(unpack('H*',hex2bin(''))); // will give me string(0) "" Whereas: var_dump(unpack('H*',hex2bin('00'))); // will give me string(2) "" and: var_dump(hex2bin('00')); // will give me string(1) "" # which is what I expect So the warning needs to be amended for an empty string as well as odd-sized hex. Additionally, the function now returns a bool(false), breaking BC. I suggest a second optional argument to return partial binary (potentially broken binary) even on error in the event the user wants to maintain backwards compatibility. I'll be happy to submit another patch for this if there are no objections. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=61660 -- Edit this bug report at https://bugs.php.net/bug.php?id=61660&edit=1