ctypes bitfield problem

[stutzbach]

BPO	9989
Nosy	@theller, @ned-deily
Superseder	bpo-6493: Can not set value for structure members larger than 32 bits

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2010-10-03.15:31:37.695>
created_at = <Date 2010-09-29.18:34:52.094>
labels = ['type-bug', 'library']
title = 'ctypes bitfield problem'
updated_at = <Date 2010-10-03.15:31:37.686>
user = 'https://bugs.python.org/stutzbach'

bugs.python.org fields:

activity = <Date 2010-10-03.15:31:37.686>
actor = 'ocean-city'
assignee = 'none'
closed = True
closed_date = <Date 2010-10-03.15:31:37.695>
closer = 'ocean-city'
components = ['Library (Lib)']
creation = <Date 2010-09-29.18:34:52.094>
creator = 'stutzbach'
dependencies = []
files = []
hgrepos = []
issue_num = 9989
keywords = []
message_count = 4.0
messages = ['117637', '117663', '117664', '117914']
nosy_count = 4.0
nosy_names = ['theller', 'ocean-city', 'ned.deily', 'stutzbach']
pr_nums = []
priority = 'normal'
resolution = 'duplicate'
stage = 'test needed'
status = 'closed'
superseder = '6493'
type = 'behavior'
url = 'https://bugs.python.org/issue9989'
versions = ['Python 3.1', 'Python 2.7', 'Python 3.2']

[stutzbach]

The following program should print "0xdead" but instead prints "0x0". This came from the following stackoverflow question:
http://stackoverflow.com/questions/3824617/python-structure-always-stuck-at-0-no-matter-what-value-you-assign-to-it

import ctypes
class Blah(ctypes.Structure):
    _fields_ = [("a", ctypes.c_uint64, 64),
                ("b", ctypes.c_uint16, 16),
                ("c", ctypes.c_uint8, 8),
                ("d", ctypes.c_uint8, 8)]

x = Blah(0xDEAD,0xBEEF,0x44,0x12)
print(hex(x.a))

[ned-deily]

An endian issue? (i.e. on OS X, it works on ppc but not Intel)
A slightly more detailed test case:

$ more test_ctypes.py
import ctypes
class Blah2(ctypes.Structure):
    _fields_ = [("x", ctypes.c_uint64, 64),
                ("y", ctypes.c_uint64)]
val = 0x0123456789ABCDEF
x = Blah2(val, val)
print(Blah2.x)
print(hex(x.x))
print(Blah2.y)
print(hex(x.y))
$ arch -i386 python2.7 test_ctypes.py
<Field type=c_ulonglong, ofs=0:0, bits=64>
0x0L
<Field type=c_ulonglong, ofs=8, size=8>
0x123456789abcdefL
$ arch -x86_64 python2.7 test_ctypes.py
<Field type=c_ulong, ofs=0:0, bits=64>
0x0L
<Field type=c_ulong, ofs=8, size=8>
0x123456789abcdefL
$ arch -ppc python2.7 test_ctypes.py
<Field type=c_ulonglong, ofs=0:0, bits=64>
0x123456789abcdefL
<Field type=c_ulonglong, ofs=8, size=8>
0x123456789abcdefL

[stutzbach]

Could be. FWIW, I had tested and observed the problem on a 32-bit Intel Windows box and 64-bit Intel Linux box.

[ocean-city]

I think this issue is duplicate of bpo-6493.