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.

Author eryksun
Recipients Ilya.Kulakov, alexei.romanov, amaury.forgeotdarc, belopolsky, eryksun, meador.inge, weeble
Date 2017-02-15.19:12:22
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1487185943.05.0.34694954794.issue22273@psf.upfronthosting.co.za>
In-reply-to
Content
ctypes defines arrays as a pointer FFI type because they degenerate as pointers in C calls. But it's generally wrong to set a pointer FFI type for an array in the `elements` of a struct's FFI type. An integer array in a struct that's 16 bytes or less should be packed in one or two general-purpose registers (rdi, rsi, rdx, rcx, r8, r9). 

For the example 16-byte struct, classify_argument() in ffi64.c expects to classify two 8-byte words. But the struct's FFI type only has one element, which we've incorrectly defined as a pointer element. Thus the second word is left at the default classification X86_64_NO_CLASS. Back in ffi_call() it expects two classified words, so it aborts when it sees X86_64_NO_CLASS.

I think we can special-case small arrays in PyCStructUnionType_update_stgdict when assigning the `elements` of the FFI type of a struct or union. If we have an array that's 32 bytes or less, unpack it as individual FFI elements, e.g. a c_ushort * 8 array would be stored as 8 ffi_type_uint16 elements in the struct's FFI type.
History
Date User Action Args
2017-02-15 19:12:23eryksunsetrecipients: + eryksun, amaury.forgeotdarc, belopolsky, weeble, meador.inge, Ilya.Kulakov, alexei.romanov
2017-02-15 19:12:23eryksunsetmessageid: <1487185943.05.0.34694954794.issue22273@psf.upfronthosting.co.za>
2017-02-15 19:12:23eryksunlinkissue22273 messages
2017-02-15 19:12:22eryksuncreate