[issue9249] struct.pack and Long Integer datatype should be 4, but is 8 bytes

hannes reuter report at bugs.python.org
Thu Jul 15 15:59:28 CEST 2010


hannes reuter <gisxperts at googlemail.com> added the comment:

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 at bugs.python.org> wrote:
>
> Mark Dickinson <dickinsm at 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 at bugs.python.org>
> <http://bugs.python.org/issue9249>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9249>
_______________________________________


More information about the Python-bugs-list mailing list