Question

得到一些像这样的代码：

some_buf = build_buffer() # returns a bytearray of ~40 bytes
align_buf(some_buf) # align it to 16 byte boundary
do_something(some_buf[16:32]) # This needs a bytes object, cannot work with bytearray

好的，让我把它改成这个：

some_buf = build_buffer() # returns a bytearray of ~40 bytes
align_buf(some_buf) # align it to 16 byte boundary
bytes_buf = bytes(some_buf)[16:32]
do_something(some_buf)

do_something（）抱怨bytes对象不是16字节对齐的。为了了解发生了什么，我添加了一个简单的条件：

some_buf = build_buffer() # returns a bytearray of ~40 bytes
align_buf(some_buf) # align it to 16 byte boundary
bytes_buf = bytes(some_buf)[16:32]
if len(some_buf) != len(bytes_buf):
    msg = "Length of bytearray ({}) != Length of bytes object ({})".format(len(some_buf), len(bytes_buf))
    raise RuntimeError(msg)
do_something(some_buf)

这就是我得到的：

RuntimeError: Length of bytearray (144) != Length of bytes object (562)

我在Windows 10 x64系统上，使用Python（CPython）解释器Python 2.7.12 (v2.7.12:d33e0cf91556, Jun 27 2016, 15:19:22) [MSC v.1500 32 bit (Intel)] on win32

之前有人见过这种行为吗？如果是这样，我在这里可能缺少的想法/线索是什么？

Answer 1

FWIW，如果看到这种行为，并且IntelHex模块在某个控制流中，则可能是一个错误。或者至少，期待这种意外行为。在将英特尔十六进制数据转换为二进制bytearray并从那里转换为bytes对象的某处，可能存在黑洞。

在这种情况下，至少可以尝试使用其他版本或其他平台（例如，启动Linux VM）以进行交叉验证。

正如评论中所提到的，在CPython '3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:18:55) [MSC v.1900 64 bit (AMD64)]'解释器上使用相同的代码路径时未观察到此行为。

Python：bytearray对象的长度与派生的bytes对象的长度不匹配？

1 个答案: