1
2There are a number of problematic special cases in XKB. The issues 
3mentioned here are at most partly resolved.
4 
51. The are several XxxDoodad structures defined in xkb.xml. They are used
6   in a few lists, but in a rather special way: 
7   The struct "CommonDoodad" is supposed to be a rather generic data type, 
8   combining the most basic Doodad fields that are common in all these structures. 
9   All Doodads are encapsulated in a union type simply called "Doodad". 
10   Now this union is used in subsequent list definitions, aiming at a kind of 
11   'polymorphism': From inspection of the protocol and Xlib, the Doodads are to 
12   be discriminated based on their type field.
13   However the special meaning of the type field is not encoded in the protocol. 
14   Furthermore the TextDoodad and the LogoDoodad are variable size types due to
15   some fields of type CountedString16, thereby turning the union into a 
16   possibly variable size type as well. 
17   However, for lists with variable size elements, special sizeof functions are 
18   required. These cannot be autogenerated as it cannot be referred which 
19   Doodad type to use for the union. 
20   Therefore, the Doodad type structures are unsupported at the moment. 
21
222. There are still some bugs in xkb.xml: Either certain fields are missing
23   that are required by the protocol, or Xlib simply has another understanding
24   of the protocol. 
25
263. The interface for accessors should be reviewed. 
27
284. Currently some bitcases carry 'name' attributes. These could be avoided if 
29   the data within would consist of a singe struct field only. 
30
315. switch could get a 'fixed_size' attribute, so when rewriting valueparam to switch, 
32   an uint32_t * pointer could be used instead of void *. 
33
346. The automatic inclusion of padding requires some complicated coding in the 
35   generator. This is errorprone and could be avoided if all padding is explicitly
36   given in the protocol definition. For variable size fields that require padding, 
37   the pad tag could get a 'fieldref' attribute. That way padding could be handled
38   a lot easier in the autogenerator.