[Xcb] names of nested structs of named bitcase/case are prone to nameclashes. Solution?

[Josh Triplett]

On Tue, Sep 02, 2014 at 03:12:28PM +0200, Christian Linhart wrote:
> 2. Not naming these structs
> 
>     ============================================
>     /**
>      * @brief xcb_input_input_state_data_t
>      **/
>     typedef struct xcb_input_input_state_data_t {
>         struct {
>                 uint8_t  num_keys; /**<  */
>             uint8_t  pad0; /**<  */
>             uint8_t  keys[32]; /**<  */
>         } key;
>         struct {
>             uint8_t  num_buttons; /**<  */
>             uint8_t  pad1; /**<  */
>             uint8_t  buttons[32]; /**<  */
>         } button;
>         struct {
>             uint8_t  num_valuators; /**<  */
>             uint8_t  mode; /**<  */
>             int32_t *valuators; /**<  */
>         } valuator;
>     } xcb_input_input_state_data_t;
>     ============================================
> 
>    Pro: is also a clean solution
> 
>    Contra: 
> 	* changes the API
> 	* struct types cannot be accessed by application-code.
> 
> 3. Workarounds in the xml, i.e. making sure that the case and bitcase-names 
>    are globally unique accross all xml-files.
> 
>    Pro: does not change the existing API
> 
>    Contra:
> 	* uqly
> 
> 	* name-clashes between different header-files are not detected by
> 	  the build of libxcb. But they may happen when building an application
> 	  that includes two headerfiles that cause a name-clash.
>  	  (However, we could add a dummy compile-step which includes all
> 	  header-files in the same C-file.).

4: use 3 for any structs we've already named to avoid changing the API,
deprecate the names, and avoid naming any new inner structs (2).  If
application code *really* needs the inner struct types, there's always
typeof().

- Josh Triplett