Bug #61660 [Com]: bin2hex(hex2bin($data)) != $data

Edit report at https://bugs.php.net/bug.php?id=61660&edit=1 ID: 61660 Comment by: theanomaly dot is at gmail dot com Reported by: krtek4+php at gmail dot com Summary: bin2hex(hex2bin($data)) != $data Status: Open Type: Bug Package: Documentation problem Operating System: Debian Linux PHP Version: 5.4.1RC1 Block user comment: N Private report: N New Comment: @laruence I've replaced the last patch with a better patch because I realized I created a memory leak and that was a poor strategy. I can't understand why there should be any confusion about whether it's an octal value or a hexadecimal value though. Since when should using bin2hex() ever leave us with the expectation that would _ever_ get back an octal value? I might be missing something here, but hex2bin() should always be expecting a hexadecimal value and bin2hex() should always leave us with the expectation of a hexadecimal value. I see nothing wrong with padding the value to an even number otherwise the result is hex2bin() isn't doing what it's supposed to be doing. It makes sense to me that even if the client sends a value of '1' that it's completely expected behavior that '01' and '1' should both be a valid hexadecimal value. To me it just makes no sense to punish the client for forgetting to pad the value by returning false data. At the very least we should be issuing a warning to let the client know they have sent unexpected data and then this can be documented behavior. But why waste time fixing it to issue E_WARNINGs when this patch fixes the issue completely? Besides hex2bin is returning a string. It's not like the user can inadvertently use it as an octal value. var_dump('0123' + '0123'); // int(246) This would be silly not to fix in my opinion. Especially since it's such an easy fix. At least run the patch and let me know which test case you can come up with that would break any of PHP's already existing documented behavior by making this modification? Previous Comments: ------------------------------------------------------------------------ [2012-04-08 08:07:32] laruence@php.net @theanomaly I have tried the similar way as you did. but the key problem is the result will be considered as a oct number. reads: "123" != "0123" ------------------------------------------------------------------------ [2012-04-08 04:38:44] theanomaly dot is at gmail dot com I've also submitted a patch which seems to work fine as far as I've tested it. Similar to the previous patch, but mine simply prepends a 0 to the beginning of every odd length string sent to hex2bin. It shouldn't break anything that I can see. If anything it just ensures we always have a valid hexadecimal representation since the implementation relies on shift 1 to translate between hex and binary (we'll always be one off). I suggest this also becomes a part of the dec2bin implementation since it would make sense to return a full octet in that representation as well. Sorry if my patch looks ugly though. This is my first attempt at a patch. ------------------------------------------------------------------------ [2012-04-07 17:12:40] krtek4+php at gmail dot com What about the patch I just sent ? I'm not sure how it will behave when converting to octal afterward, but at least we don't loose the last hexadecimal number, so I think it's an improvement over the actual situation. ------------------------------------------------------------------------ [2012-04-07 17:04:25] laruence@php.net actually, I think I can not make a good patch for this, since 0* will be considerd as a oct number... and if I pad some magic number like '0f' to it, there will be a mess if you pass the result to somewhere not bin2hex.. so, mark this as doc problem ------------------------------------------------------------------------ [2012-04-07 16:46:29] laruence@php.net I think it's better to well document this. or, add a prepend '0' , I will make a patch for this. ------------------------------------------------------------------------ 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