There are a number of problematic special cases in XKB. The issues 

mentioned here are at most partly resolved.

1. The are several XxxDoodad structures defined in xkb.xml. They are used

   in a few lists, but in a rather special way: 

   The struct "CommonDoodad" is supposed to be a rather generic data type, 

   combining the most basic Doodad fields that are common in all these structures. 

   All Doodads are encapsulated in a union type simply called "Doodad". 

   Now this union is used in subsequent list definitions, aiming at a kind of 

   'polymorphism': From inspection of the protocol and Xlib, the Doodads are to 

   be discriminated based on their type field.

   However the special meaning of the type field is not encoded in the protocol. 

   Furthermore the TextDoodad and the LogoDoodad are variable size types due to

   some fields of type CountedString16, thereby turning the union into a 

   possibly variable size type as well. 

   However, for lists with variable size elements, special sizeof functions are 

   required. These cannot be autogenerated as it cannot be referred which 

   Doodad type to use for the union. 

   Therefore, the Doodad type structures are unsupported at the moment. 

2. There are still some bugs in xkb.xml: Either certain fields are missing

   that are required by the protocol, or Xlib simply has another understanding

   of the protocol. 

3. The interface for accessors should be reviewed. 

4. Currently some bitcases carry 'name' attributes. These could be avoided if 

   the data within would consist of a singe struct field only. 

5. switch could get a 'fixed_size' attribute, so when rewriting valueparam to switch, 

   an uint32_t * pointer could be used instead of void *. 

6. The automatic inclusion of padding requires some complicated coding in the 

   generator. This is errorprone and could be avoided if all padding is explicitly

   given in the protocol definition. For variable size fields that require padding, 

   the pad tag could get a 'fieldref' attribute. That way padding could be handled

   a lot easier in the autogenerator.