struct curiosity

[pjcoup]

Hello,

I was fooling around with python's struct lib, looking on how we'd
unpack some data. I was a little confused by its behavior:
Python 2.5.2 (r252:60911, Jul 22 2009, 15:33:10)
[GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.10

I would have expected calcsize('BhhhhB') to be either 10 or 12
(padding), but 11?
Is there a simple explanation of what is going on here? Just a
curiosity.
This is on a x86_64, but have seen the same on i686. Ideas?

Thanks.
Pete

 

[Richard Brodie]

I would have expected calcsize('BhhhhB') to be either 10 or 12
(padding), but 11? Is there a simple explanation of what is going
on here?

The purpose of the padding is to align the words 'naturally'.
That is, when reading two bytes, to start at an even number.

B X B h1
h1 h1 h1 h2
h2 h2 h2 h3
h3 h3 h3 h4
h4 h4 h4 B
B Y

The padding at X lines up h1-h4. There isn't any point
putting padding at Y.

 

[Peter Otten]

The purpose of the padding is to align the words 'naturally'.
That is, when reading two bytes, to start at an even number.

B X B h1
h1 h1 h1 h2
h2 h2 h2 h3
h3 h3 h3 h4
h4 h4 h4 B
B Y

The padding at X lines up h1-h4. There isn't any point
putting padding at Y.

I would have expected "native size and alignment" (as stated in the
documentation) to mean that I can read the output of struct.pack("bhhhhb")
into a C

struct {
char a;
short b1, b2, b3, b4;
char c
}

but that has a size of 12 bytes on my 64 bit Ubuntu.

Peter

 

[Mark Dickinson]

I was fooling around with python's struct lib, looking on how we'd
unpack some data.  I was a little confused by its behavior:
Python 2.5.2 (r252:60911, Jul 22 2009, 15:33:10)
[GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.>>> import struct11

This result *includes* any necessary padding between two
consecutive fields of the struct (in this case, the extra
byte of padding between the first 'B' and the following
'h', but *excludes* padding at the end of the struct.
The result of struct.pack with one of these formats should
have length exactly 11: the struct module doesn't bother
including the trailing padding.

10

The non-native formats don't include padding at all.

Mark

 

[Gabriel Genellina]

10

I would have expected calcsize('BhhhhB') to be either 10 or 12
(padding), but 11?

There are no pad bytes following the last member; from the docs:

"""Hint: to align the end of a structure to the alignment requirement of a
particular type, end the format with the code for that type with a repeat
count of zero. For example, the format 'llh0l' specifies two pad bytes at
the end, assuming longs are aligned on 4-byte boundaries. This only works
when native size and alignment are in effect; standard size and alignment
does not enforce any alignment."""

py> calcsize("BhhhhB")
11
py> calcsize("BhhhhB0h")
12

 

[Gabriel Genellina]

10

I would have expected calcsize('BhhhhB') to be either 10 or 12
(padding), but 11?

There are no pad bytes following the last member; from the docs:

"""Hint: to align the end of a structure to the alignment requirement of a
particular type, end the format with the code for that type with a repeat
count of zero. For example, the format 'llh0l' specifies two pad bytes at
the end, assuming longs are aligned on 4-byte boundaries. This only works
when native size and alignment are in effect; standard size and alignment
does not enforce any alignment."""

py> calcsize("BhhhhB")
11
py> calcsize("BhhhhB0h")
12

 

[pjcoup]

Yes, this is basically what I expected as well.
I would have expected some size that you can coax gcc to give, either
12 (as here), or 10 (with directives).
Thanks to everyone for the responses!

Pete