]> git.ipfire.org Git - thirdparty/Python/cpython.git/commit
[2.7] bpo-10746: Fix ctypes PEP 3118 type codes for c_long, c_bool, c_int (GH-31...
authorPauli Virtanen <pav@iki.fi>
Sat, 2 Sep 2017 16:24:32 +0000 (18:24 +0200)
committerAntoine Pitrou <pitrou@free.fr>
Sat, 2 Sep 2017 16:24:32 +0000 (18:24 +0200)
commit990b2d043cdfaafc3378550f7d27259410a6b918
tree47e272fa173e981b2ec1695052bf305ecdf3826e
parent20958e6d91d11a80d6c664ce6346791259b1d193
[2.7] bpo-10746: Fix ctypes PEP 3118 type codes for c_long, c_bool, c_int (GH-31) (#3242)

[2.7] bpo-10746: Fix ctypes PEP 3118 type codes for c_long, c_bool, c_int (GH-31)

Ctypes currently produces wrong pep3118 type codes for several types.
E.g. memoryview(ctypes.c_long()).format gives "<l" on 64-bit platforms,
but it should be "<q" instead for sizeof(c_long) == 8

The problem is that the '<>' endian specification in the struct syntax
also turns on the "standard size" mode, which makes type characters have
a platform-independent meaning, which does not match with the codes used
internally in ctypes.  The struct module format syntax also does not
allow specifying native-size non-native-endian items.

This commit adds a converter function that maps the internal ctypes
codes to appropriate struct module standard-size codes in the pep3118
format strings. The tests are modified to check for this..
(cherry picked from commit 07f1658aa09f6798793c473c72b2951b7fefe220)
Lib/ctypes/test/test_pep3118.py
Misc/NEWS.d/next/Library/2017-08-28-13-01-05.bpo-10746.nmAvfu.rst [new file with mode: 0644]
Modules/_ctypes/_ctypes.c