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.