Charles Machalow added the comment: Took a quick look at the c code for this. The area at fault appears to be this section in cfield.c:
#ifndef MS_WIN32 } else if (bitsize /* this is a bitfield request */ && *pfield_size /* we have a bitfield open */ && dict->size * 8 >= *pfield_size && (*pbitofs + bitsize) <= dict->size * 8) { /* expand bit field */ fieldtype = EXPAND_BITFIELD; #endif The problem seems to be after the end of the 2nd c_uint16, it seems to think that the next 10 bytes should extend that c_uint16 to a c_uint32 instead of taking the type as the beginning of a new c_uint32. So I guess it is making the structure something like this: ("P", c_uint16), ("L", c_uint32, 9), ("Pro", c_uint32, 1), ("G", c_uint32, 1), ("IB", c_uint32, 1), ("IR", c_uint32, 1), ("R", c_uint32, 3), ("T", c_uint32, 10), # And now this needs an extra 6 bits of padding to fill the c_uint32 ("C", c_uint32, 20), ("R2", c_uint32, 2) # And now this needs an extra 10 bits of padding to fill the c_uint32. I guess that is how we get to 10... instead of the expected 8 bytes. I don't believe that this behavior is desired nor really makes logical sense. ---------- _______________________________________ 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