Unpacking problem

[Chris Garland]

What's wrong here?

>>from struct import unpack

I can unpack an unsigned char

>>unpack('B','\x90')

(144,)

I can unpack a short

>>unpack('h','\x06\x00')

(6,)

But an unsigned char & a short give me this

>>unpack('Bh','\x90\x06\x00')

Traceback (most recent call last):
File "<stdin>", line 1, in ?
struct.error: unpack str size does not match format

>>>

[Marc 'BlackJack' Rintsch]

In <11*********************@h3g2000cwc.googlegroups.c om>, Chris Garland
wrote:

But an unsigned char & a short give me this

>>>unpack('Bh','\x90\x06\x00')

Traceback (most recent call last):
File "<stdin>", line 1, in ?
struct.error: unpack str size does not match format

Let's pack this:

In [90]: pack('Bh', 0x90, 0x6)
Out[90]: '\x90\x00\x06\x00'

Per default the values are (un)packed with the preferred alignment of the
C compiler, so here is an extra byte to place the short at an even
address. If you give the endianess in the format string there's no
padding:

In [91]: pack('<Bh', 0x90, 0x6)
Out[91]: '\x90\x06\x00'

Ciao,
Marc 'BlackJack' Rintsch

[timm.gloger]

The problem is, that len('\x90\x06\x00') is not equivalent to
calcsize('Bh'):

>>calcsize('Bh')

4

>>len('\x90\x06\x00')

3

Actually calculating the size for 'hB' results in:

>>calcsize('hB')

3

So far I have not figured out, why there is an additional byte, but it
does not effect the result in any way. (Or I simply did not insert any
byte that would cause an effect.)

So

>>unpack('Bh', '\x90\x??\x06\x00')

(144,6)

with ?? as any valid hex, gives the "correct" result, but I dont know
why either.

On Mar 1, 10:17 pm, "Chris Garland" <[e-mail]:

What's wrong here?

>from struct import unpack

I can unpack an unsigned char>>unpack('B','\x90')

(144,)

I can unpack a short>>unpack('h','\x06\x00')

(6,)

But an unsigned char & a short give me this>>unpack('Bh','\x90\x06\x00')

Traceback (most recent call last):
File "<stdin>", line 1, in ?
struct.error: unpack str size does not match format

[timm.gloger]

Ok, that solves my confusion.
Thanks, Marc.