This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: struct.pack and Long Integer datatype should be 4, but is 8 bytes
Type: behavior Stage:
Components: Extension Modules Versions: Python 2.6
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: mark.dickinson Nosy List: hannes.reuter, mark.dickinson, meador.inge, theller
Priority: normal Keywords:

Created on 2010-07-13 15:00 by hannes.reuter, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (5)
msg110201 - (view) Author: hannes reuter (hannes.reuter) Date: 2010-07-13 15:00
on http://docs.python.org/library/struct.html
in section 7.3.2.2. Format Characters in the table one can find that 
L -> unsigned long -> 	integer-> should have a 4 byte dataspace.
(same applies for l), which seems to be correct -> 32bit/8=4


On a Ubuntu 64 , Python 2.6,  
a) calcsize reports it uses 8 byte
b) by writing data to a file and reading it back in I could confirm that it uses as well 8 bytes of binary data -> ofile2.write(struct.pack('LL',int(x[0]), int(x[1])))

Q: Is that behavior what we see a Docu error ?
Q: Is that behavior what we see general struct problem ? 
add1: in # 2263 e.g. we see problems for L type data in relation to np ?  
add2: IMHO certainly not a padding problem like in #7355


for reproduction:

from struct import *
calcsize('H')
2 -> correct to docu
calcsize('f')
4 -> correct to docu
calcsize('L')
8   -> should be 4
calcsize('l')
8 -> should be 4
calcsize('x')
1 -> correct to docu

So either docu is wrong, or struct has an error.
msg110223 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-07-13 19:57
Please read the three sentences directly preceding that table and tell me whether they clear this up for you.
msg110278 - (view) Author: hannes reuter (hannes.reuter) Date: 2010-07-14 13:16
Dear Marc,

Thanks for taking time to answer that question. I understand that this
comes from the native formating i specified,
>>> calcsize('L')
8
>>> calcsize('<L')
4

So if written with < or = it is 4 bytes, clear.

However, as my system is a little endian one(e.g.
sys.byteorder=little), whats the difference between native and little
?  I understand that Alignment is not performed on the Native format,
a) but why is only L/l shows a difference compared to the
table(docu)/formated output in the in native format , while the rest
agrees one to one ?
b) Where could I look up/find such a native format table ?

Probably you can answer that easily to me, I'm just really,really puzzled.

Hannes

for x in list:
... 	print x,calcsize(x),calcsize('<'+x)
...
x 1 1
c 1 1
b 1 1
B 1 1
? 1 1
h 2 2
H 2 2
i 4 4
I 4 4
l 8 4
L 8 4
q 8 8
Q 8 8
f 4 4
d 8 8
s 1 1
p 1 1

'little'

On 7/13/10, Mark Dickinson <report@bugs.python.org> wrote:
>
> Mark Dickinson <dickinsm@gmail.com> added the comment:
>
> Please read the three sentences directly preceding that table and tell me
> whether they clear this up for you.
>
> ----------
> assignee: theller -> mark.dickinson
> nosy: +mark.dickinson
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue9249>
> _______________________________________
>
msg110312 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-07-14 18:59
> However, as my system is a little endian one(e.g.
> sys.byteorder=little), whats the difference between native and little

Native mode uses:  native size, native byteorder and alignment that
  matches your platform
Little endian: standard size, little-endian, no alignment

The *native* size means the size of the corresponding C type (e.g., as computed by sizeof) on your platform.  So on a typical 64-bit Unix-alike platform, that's 8 for 'l' and 'L'; on 64-bit Windows and most 32-bit platforms, it's 4 for 'l' and 'L'.

The *standard* size is as given by the table.  It's the same on all platforms.

It's true that on most common platforms the 'l' and 'L' codes are the only ones likely to differ.

> b) Where could I look up/find such a native format table ?
Why not just use struct.calcsize?

This is all explained in the docs;  I'm going to close this issue, since I don't think there's any discrepancy between the docs and the behaviour of the module.

However, if you have ideas for specific improvements to the documentation, please do open another issue.
msg110367 - (view) Author: hannes reuter (hannes.reuter) Date: 2010-07-15 13:59
Hi Mark,

If you would add a footnote to the L/l formats table and mention what
you wrote, it would make things clearer. Something along the lines
like that I reformulated from your explanation:

On most common platforms the 'l' and 'L' codes are the only ones
likely to differ due to formating differences between Native and
Little are. The Size for 'l' and 'L' on a typical 64-bit Unix-alike
platform will be 8 for 'l' and 'L'; on 64-bit Windows and most 32-bit
platforms, it's 4.   This is due to the fact that in Native mode
native size, native byteorder and alignment will be set, while with a
Little endian formating standard size, little-endian, no alignment
will be set.
<<

Cheers Hannes

On 7/14/10, Mark Dickinson <report@bugs.python.org> wrote:
>
> Mark Dickinson <dickinsm@gmail.com> added the comment:
>
>> However, as my system is a little endian one(e.g.
>> sys.byteorder=little), whats the difference between native and little
>
> Native mode uses:  native size, native byteorder and alignment that
>   matches your platform
> Little endian: standard size, little-endian, no alignment
>
> The *native* size means the size of the corresponding C type (e.g., as
> computed by sizeof) on your platform.  So on a typical 64-bit Unix-alike
> platform, that's 8 for 'l' and 'L'; on 64-bit Windows and most 32-bit
> platforms, it's 4 for 'l' and 'L'.
>
> The *standard* size is as given by the table.  It's the same on all
> platforms.
>
> It's true that on most common platforms the 'l' and 'L' codes are the only
> ones likely to differ.
>
>> b) Where could I look up/find such a native format table ?
> Why not just use struct.calcsize?
>
> This is all explained in the docs;  I'm going to close this issue, since I
> don't think there's any discrepancy between the docs and the behaviour of
> the module.
>
> However, if you have ideas for specific improvements to the documentation,
> please do open another issue.
>
> ----------
> status: open -> closed
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue9249>
> _______________________________________
>
History
Date User Action Args
2022-04-11 14:57:03adminsetgithub: 53495
2010-08-02 02:49:44meador.ingesetnosy: + meador.inge
2010-07-15 13:59:27hannes.reutersetmessages: + msg110367
2010-07-14 18:59:50mark.dickinsonsetstatus: open -> closed

messages: + msg110312
2010-07-14 13:16:25hannes.reutersetstatus: pending -> open

messages: + msg110278
2010-07-14 02:56:21mark.dickinsonsetstatus: open -> pending
nosy: theller, mark.dickinson, hannes.reuter
resolution: not a bug
components: + Extension Modules, - ctypes
2010-07-13 19:57:14mark.dickinsonsetassignee: theller -> mark.dickinson

messages: + msg110223
nosy: + mark.dickinson
2010-07-13 15:00:06hannes.reutercreate