Edit report at https://bugs.php.net/bug.php?id=61660&edit=1
ID: 61660
Updated by: nikic@php.net
Reported by: krtek4+php at gmail dot com
Summary: bin2hex(hex2bin($data)) != $data
-Status: Open
+Status: Closed
Type: Bug
Package: *General Issues
Operating System: Debian Linux
PHP Version: 5.4.1RC1
-Assigned To:
+Assigned To: nikic
Block user comment: N
Private report: N
New Comment:
After some further discussion on IRC we agreed that it is best to throw a warning. The reasoning is
as outlined in my previous comment.
The warning is implemented with https://github.com/php/php-src/commit/7ae93a2c4c8a51cc2aec9977ce3c83c100e382a0.
Previous Comments:
------------------------------------------------------------------------
[2012-04-08 20:45:41] nikic@php.net
Automatic comment on behalf of nikic
Revision: http://git.php.net/?p=php-src.git;a=commit;h=7ae93a2c4c8a51cc2aec9977ce3c83c100e382a0
Log: Fix bug #61660: bin2hex(hex2bin($data)) != $data
------------------------------------------------------------------------
[2012-04-08 16:23:50] theanomaly dot is at gmail dot com
We have no problem type juggling a string to an int as the first non-whitespace,
non-zero number character...
var_dump(1 + "\t\r\n 0001"); // int(2)
Then, equally, we should have no problem interpreting a hexadecimal
representation of 1 as 01.
:)
------------------------------------------------------------------------
[2012-04-08 16:05:02] rasmus@php.net
> 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".
Why would af52b ever mean af52b0 ? That's like saying 15 could be interpreted as
150 sometimes.
------------------------------------------------------------------------
[2012-04-08 15:25:52] nikic@php.net
In my eyes hex2bin should not try to fix the corrupt data by padding it with zero. Instead it should
throw a warning.
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".
Both are valid interpretations, depending on the use case.
Because of this I think a warning is more appropriate. It signals the user that the data is wrong.
He can always easily fix it by adding a zero to either of the sides, whatever is more appropriate in
his particular situation.
Blindly adding the padding on the other hand will probably be quite unexpected. Especially when
adding the 0 on the left side all the data will be shifted by 4 bits. This means that the whole data
will be corrupted. All bytes will change. (Adding a padding on the right is less intrusive as it
only changes one byte).
------------------------------------------------------------------------
[2012-04-08 13:20:35] krtek4+php at gmail dot com
You are right, there was a bug in the patch I sent. I updated it on github.
Thanks for the comment !
------------------------------------------------------------------------
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