Mark Dickinson <[email protected]> added the comment:
> Finally, I think proposed allocation seems correct, but I must admit I
> am not clever enough to follow why the following part works :-)
Nor am I, any more, though it made sense when I wrote it. I'll see if I can
make that a bit more readable.
I see two goals here: (1) make the allocation sane and self-consistent, and
also ideally document the algorithm ctypes uses (I know there's another issue
already open for this), and (2) make the allocation match common compilers.
(2) may not be easy / possible...
I did some random testing on my machine (x64, OS X, gcc 4.2), which seems to
show that the bitfield allocation algorithm for gcc works roughly like this:
def simulated_layout(flags):
bitpos = 0
for ctype, width in flags:
if width is None:
# Plain old integer field (not a bitfield)
width = 8 * sizeof(ctype)
space = -bitpos % (8 * sizeof(ctype))
if width > space:
bitpos += space
offset, start = divmod(bitpos, 8 * sizeof(ctype))
yield offset * sizeof(ctype), start, width
bitpos += width
At least, my simple and limited random tests have yet to discover a case where
this differs from what gcc actually does on my machine, while they're pretty
quick to find differences between what gcc does and what ctypes does. I've
attached the script in case it's of interest (please don't judge too
harshly---it was written quickly and the style leaves something to be desired).
In particular, I didn't include signed integers in the tests; sounds like
that's a potential complicating factor.
----------
Added file: http://bugs.python.org/file26084/ctypes_bitfields.py
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue15119>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
