binhex buggy in py3k

[pitrou]

BPO	6369
Nosy	@amauryfa, @pitrou
Files	binhex.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields: ```python assignee = None closed_at = created_at = labels = ['type-bug', 'library'] title = 'binhex buggy in py3k' updated_at = user = 'https://github.com/pitrou' ``` bugs.python.org fields: ```python activity = actor = 'pitrou' assignee = 'none' closed = True closed_date = closer = 'pitrou' components = ['Library (Lib)'] creation = creator = 'pitrou' dependencies = [] files = ['14384'] hgrepos = [] issue_num = 6369 keywords = ['patch'] message_count = 5.0 messages = ['89842', '89845', '89891', '89921', '89980'] nosy_count = 2.0 nosy_names = ['amaury.forgeotdarc', 'pitrou'] pr_nums = [] priority = 'normal' resolution = 'fixed' stage = 'patch review' status = 'closed' superseder = None type = 'behavior' url = 'https://bugs.python.org/issue6369' versions = ['Python 3.1', 'Python 3.2'] ```

[pitrou]

The binhex module is buggy in py3k, witness the following example (it works ok on trunk):

>>> binhex.binhex("README", "testA")
>>> binhex.hexbin("testA", "outA")
>>> binhex.binhex("LICENSE", "testB")
>>> binhex.hexbin("testB", "outB")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/antoine/py3k/__svn__/Lib/binhex.py", line 445, in hexbin
    ifp = HexBin(inp)
  File "/home/antoine/py3k/__svn__/Lib/binhex.py", line 364, in __init__
    self._readheader()
  File "/home/antoine/py3k/__svn__/Lib/binhex.py", line 384, in _readheader
    rest = self._read(1 + 4 + 4 + 2 + 4 + 4)
  File "/home/antoine/py3k/__svn__/Lib/binhex.py", line 367, in _read
    data = self.ifp.read(len)
  File "/home/antoine/py3k/__svn__/Lib/binhex.py", line 300, in read
    self._fill(wtd - len(self.post_buffer))
  File "/home/antoine/py3k/__svn__/Lib/binhex.py", line 337, in _fill
    binascii.rledecode_hqx(self.pre_buffer[:mark])
binascii.Error: Orphaned RLE code at start

[pitrou]

The bug is due to bytes-indexing returning an int in py3k while it returns another bytes object in trunk. Here is a patch. I don't know how to reliably test for it, though.

[amauryfa]

Believe it or not, the failing test is already in svn: http://mail.python.org/pipermail/python-checkins/2009-June/084616.html

[pitrou]

Well, failure or success of the current tests seems to rely on the length of the filename being tested! :-)

[pitrou]

Fixed in r73747 and r73748.