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
