osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

array and struct 64-bit Linux change in behavior Python 3.7 and 2.7



> On 2 Dec 2019, at 17:55, Rob Gaddi <rgaddi at highlandtechnology.invalid> wrote:
> 
> On 12/2/19 9:26 AM, Chris Clark wrote:
>> Test case:
>>                import array
>>                array.array('L', [0])
>> # x.itemsize == 8  rather than 4
>> This works fine (returns 4) under Windows Python 3.7.3 64-bit build.
>> Under Ubuntu; Python 2.7.15rc1, 3.6.5, 3.70b3 64-bit this returns 8. Documentation at https://docs.python.org/3/library/array.html explicitly states 'L' is for size 4.
>> It impacts all uses types of array (e.g. reading from byte strings).
>> The struct module is a little different:
>> import struct
>> x = struct.pack('L', 0)
>> # len(x) ===8 rather than 4
>> This can be worked around by using '=L' - which is not well documented - so this maybe a doc issue.
>> Wanted to post here for comments before opening a bug at https://bugs.python.org/
>> Is anyone seeing this under Debian/Ubuntu?
>> Chris
> 
> I'd say not a bug, at least in array.  Reading that array documentation you linked, 4 is explicitly the MINIMUM size in bytes, not the guaranteed size.

I'm wondering how useful it is that for array you can read from a file but have no ideas how many bytes each item needs.
If I have a file with int32_t  in it I cannot from the docs know how to read that file into an array.

> 
> The struct situation is, as you said, a bit different.  I believe that with the default native alignment @, you're seeing 4-byte data padded to an 8-byte alignment, not 8-byte data.  That does seem to go against what the struct documentation says, "Padding is only automatically added between successive structure members. No padding is added at the beginning or the end of the encoded struct."

The 'L' in struct is documented for 3.7 to use 4 bytes, but in fact uses 8, on fedora 31. Doc bug?

>>> x=struct.pack('L',0x102030405)
>>> x
b'\x05\x04\x03\x02\x01\x00\x00\x00'

Given I have exact control with b, h, i, and q but L is not fixed in size I'm not sure how it can be used with certainty across OS and versions.

Barry


> 
> = alignment is documented as having the platform native byte-order, but the size and alignment is standardized as having no padding, which is exactly the behavior you seem to want. The documentation is a bit obtuse and scattered, but no more than any other.
> -- 
> https://mail.python.org/mailman/listinfo/python-list <https://mail.python.org/mailman/listinfo/python-list>