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

From: Date: Sun, 06 May 2012 23:12:17 +0000
Subject: Bug #61660 [ReO]: bin2hex(hex2bin($data)) != $data
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-170270@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:         nikic@php.net
 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:

bin2hex already now returns a valid hex string. This bug report is about the inverse function
hex2bin, which converts a hexadecimally encoded binary string back into a binary string. (Please
note that we are not talking about NUMBERs here, but about STRINGs.)

So I'm not quite sure what the problem is there.


Previous Comments:
------------------------------------------------------------------------
[2012-05-06 23:03:54] personal_homepage_tools at hochsitze dot com

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*

------------------------------------------------------------------------
[2012-05-06 23:02:49] nikic@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] nikic@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] stas@php.net

I do not think BC break in 5.4 is a good idea.

------------------------------------------------------------------------


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


Thread (18 messages)

« previous php.bugs (#170270) next »