summaryrefslogtreecommitdiffstats
path: root/Python/getopt.c
diff options
context:
space:
mode:
authorPauli Virtanen <pav@iki.fi>2017-08-30 09:40:05 (GMT)
committerAntoine Pitrou <pitrou@free.fr>2017-08-30 09:40:05 (GMT)
commit2d1653aa43cf02e6b74f9d4f178fac9969a293e2 (patch)
tree24c1b3dc7a874baabcb8d81d0fc559b13e72955d /Python/getopt.c
parent87c50245b1ba21469cc2e4e84cd5e5cd54ff954d (diff)
downloadcpython-2d1653aa43cf02e6b74f9d4f178fac9969a293e2.zip
cpython-2d1653aa43cf02e6b74f9d4f178fac9969a293e2.tar.gz
cpython-2d1653aa43cf02e6b74f9d4f178fac9969a293e2.tar.bz2
[3.6] bpo-10746: Fix ctypes PEP 3118 type codes for c_long, c_bool, c_int (GH-31) (#3241)
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)
Diffstat (limited to 'Python/getopt.c')
0 files changed, 0 insertions, 0 deletions