[Xcb] using enums as type in sync.xml

[Ian Osgood]

On Sep 5, 2007, at 8:56 AM, Thomas Hunger wrote:

> Hello,
>
> sync.xml uses enums as types. This is readable, but a problem because
>
> 1) enums can have different binary sizes on different
>    platforms and depending on the range they cover.
>
> 2) The size required in the X protocoll might not be the same
>    as the native platform enum size (this is very prominent in
>    XKB which uses 1, 2 and 4 byte enumerations in X).
>
>   <struct name="TRIGGER">
>     <field type="COUNTER" name="counter" />
>     <field type="VALUETYPE" name="wait_type" />
>     <field type="INT64" name="wait_value" />
>     <field type="TESTTYPE" name="test_type" />
>   </struct>
>
> An easy workaround is to define
>
>   <typedef newname="VALUETYPE" oldname="CARD32"/>
>   <typedef newname="TESTTYPE" oldname="CARD32"/>
>
> A patch is attached.
>
> tom
> <0001-Let-types-point-to-typedefs-instead-of-enums-to-ensu.patch>

Comments:

 > +  <enum name="ALARMSTATE_ENUM">

I don't like this naming convention.

My recommendation:

In other requests, we replaced the enum typename in the request with  
the cardinal of the appropriate size, in this case:

-     <field type="VALUETYPE" name="wait_type" />
+     <field type="CARD32" name="wait_type" />  <!-- enum VALUETYPE -->
       <field type="INT64" name="wait_value" />
-     <field type="TESTTYPE" name="test_type" />
+     <field type="CARD32" name="test_type" />   <!-- enum TESTTYPE -->

This is not ideal for language bindings other than C, because we are  
losing type information. We have discussed in the past enhancing our  
<field> description to take both an optional size and a type in order  
to handle this problem. (We can't give the enum a size because it may  
be reused in different requests for fields with differing sizes.)

(Another option is to define a union type for these fields. The union  
for the wait_type field would expand to:
union {
   uint32 space;
   enum XCB_VALUETYPE_T e;
} xcb_wait_field_t ;
but this might run into MSB/LSB portability problems.)

Ian