121298544Smrg 221298544SmrgThere are a number of problematic special cases in XKB. The issues 321298544Smrgmentioned here are at most partly resolved. 421298544Smrg 521298544Smrg1. The are several XxxDoodad structures defined in xkb.xml. They are used 621298544Smrg in a few lists, but in a rather special way: 721298544Smrg The struct "CommonDoodad" is supposed to be a rather generic data type, 821298544Smrg combining the most basic Doodad fields that are common in all these structures. 921298544Smrg All Doodads are encapsulated in a union type simply called "Doodad". 1021298544Smrg Now this union is used in subsequent list definitions, aiming at a kind of 1121298544Smrg 'polymorphism': From inspection of the protocol and Xlib, the Doodads are to 1221298544Smrg be discriminated based on their type field. 1321298544Smrg However the special meaning of the type field is not encoded in the protocol. 1421298544Smrg Furthermore the TextDoodad and the LogoDoodad are variable size types due to 1521298544Smrg some fields of type CountedString16, thereby turning the union into a 1621298544Smrg possibly variable size type as well. 1721298544Smrg However, for lists with variable size elements, special sizeof functions are 1821298544Smrg required. These cannot be autogenerated as it cannot be referred which 1921298544Smrg Doodad type to use for the union. 2021298544Smrg Therefore, the Doodad type structures are unsupported at the moment. 2121298544Smrg 2221298544Smrg2. There are still some bugs in xkb.xml: Either certain fields are missing 2321298544Smrg that are required by the protocol, or Xlib simply has another understanding 2421298544Smrg of the protocol. 2521298544Smrg 2621298544Smrg3. The interface for accessors should be reviewed. 2721298544Smrg 2821298544Smrg4. Currently some bitcases carry 'name' attributes. These could be avoided if 2921298544Smrg the data within would consist of a singe struct field only. 3021298544Smrg 3121298544Smrg5. switch could get a 'fixed_size' attribute, so when rewriting valueparam to switch, 3221298544Smrg an uint32_t * pointer could be used instead of void *. 3321298544Smrg 3421298544Smrg6. The automatic inclusion of padding requires some complicated coding in the 3521298544Smrg generator. This is errorprone and could be avoided if all padding is explicitly 3621298544Smrg given in the protocol definition. For variable size fields that require padding, 3721298544Smrg the pad tag could get a 'fieldref' attribute. That way padding could be handled 3821298544Smrg a lot easier in the autogenerator.