Eryk Sun added the comment:
To make it simpler to diagram the fields, I've rewritten your structure using
field names A-J:
import ctypes
class MyStructure(ctypes.Structure):
_pack_ = 1
_fields_ = (('A', ctypes.c_uint16), # 2 bytes
('B', ctypes.c_uint16, 9),
('C', ctypes.c_uint16, 1),
('D', ctypes.c_uint16, 1),
('E', ctypes.c_uint16, 1),
('F', ctypes.c_uint16, 1),
('G', ctypes.c_uint16, 3), # 4 bytes
('H', ctypes.c_uint32, 10),
('I', ctypes.c_uint32, 20),
('J', ctypes.c_uint32, 2)) # 8 bytes
ctypes is attempting to extend the bitfield for H by switching to a c_uint
storage unit with an offset of 2 bytes and adding H field with a 16-bit offset:
>>> MyStructure.H
<Field type=c_uint, ofs=2:16, bits=10>
Here's the correct layout:
| uint16 | uint16 | uint32
|------16-------|------16-------|---10----|--------20---------|-
A---------------B--------CDEFG--H---------I-------------------J-
and here's the layout that ctypes creates, which wastes 2 bytes:
| uint32 |
| uint16 | uint16 | | uint32
|------16-------|------16-------|---10----|--6--|--------20---------|-|---10----
A---------------B--------CDEFG--H---------------I-------------------J-----------
The current strategy for extending bitfields to work like gcc on Linux is
obviously failing us here. Hopefully someone can flesh out the exact rules to
make this code accurate. Bitfields are such a pain.
----------
nosy: +eryksun
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29753>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
