New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
struct.pack and Long Integer datatype should be 4, but is 8 bytes #53495
Comments
on http://docs.python.org/library/struct.html On a Ubuntu 64 , Python 2.6, Q: Is that behavior what we see a Docu error ? 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. |
Please read the three sentences directly preceding that table and tell me whether they clear this up for you. |
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. 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:
|
Native mode uses: native size, native byteorder and alignment that 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.
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. |
Hi Mark, If you would add a footnote to the L/l formats table and mention what On most common platforms the 'l' and 'L' codes are the only ones Cheers Hannes On 7/14/10, Mark Dickinson <report@bugs.python.org> wrote:
|
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: