diff options
| author | Pauli Virtanen <pav@iki.fi> | 2017-08-28 12:08:49 (GMT) |
|---|---|---|
| committer | Antoine Pitrou <pitrou@free.fr> | 2017-08-28 12:08:49 (GMT) |
| commit | 07f1658aa09f6798793c473c72b2951b7fefe220 (patch) | |
| tree | 1a3c4c0603a5e3fac9b8d2ec1a96a9445291d392 /Misc | |
| parent | a30f6d45ac3e72761b96a8df0527182029eaee24 (diff) | |
| download | cpython-07f1658aa09f6798793c473c72b2951b7fefe220.zip cpython-07f1658aa09f6798793c473c72b2951b7fefe220.tar.gz cpython-07f1658aa09f6798793c473c72b2951b7fefe220.tar.bz2 | |
bpo-10746: Fix ctypes PEP 3118 type codes for c_long, c_bool, c_int (#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.
Diffstat (limited to 'Misc')
| -rw-r--r-- | Misc/NEWS.d/next/Library/2017-08-28-13-01-05.bpo-10746.nmAvfu.rst | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/Misc/NEWS.d/next/Library/2017-08-28-13-01-05.bpo-10746.nmAvfu.rst b/Misc/NEWS.d/next/Library/2017-08-28-13-01-05.bpo-10746.nmAvfu.rst new file mode 100644 index 0000000..e762563 --- /dev/null +++ b/Misc/NEWS.d/next/Library/2017-08-28-13-01-05.bpo-10746.nmAvfu.rst @@ -0,0 +1 @@ +Fix ctypes producing wrong PEP 3118 type codes for integer types. |