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.