> 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.