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

From: Date: Sun, 08 Apr 2012 08:07:32 +0000
Subject: Bug #61660 [Opn]: bin2hex(hex2bin($data)) != $data
References: 1  Groups: php.doc.bugs 
Request: Send a blank email to doc-bugs+get-8225@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=61660&edit=1 ID: 61660 Updated by: laruence@php.net 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: @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" Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [2012-04-07 16:45:45] krtek4+php at gmail dot com I'm aware that this is a problem with the internal reprensation of the binary value which has to be aligned on 8 bits. But with the actual implementation, we are losing informations. A possible solution would be to pad the binary data with 0 on the left and when converting back again to hex, remove the leading 0s. At least, something should be said in the documentation about this shortcoming. ------------------------------------------------------------------------ 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

« previous php.doc.bugs (#8225) next »