[Xcb] _Problems_ in GSoC, 2011

[Evgeny M. Zubok]

"Evgeny M. Zubok" <evgeny.zubok at tochka.ru>
writes:

>> - For StructType and UnionType, the alignment is the maximum alignment
>>   needed by any field in the struct or union. So STR, which is a struct
>>   containing a CARD8 and a list of CARD8, only needs 1-byte alignment;
>>   but a struct containing an INT16 and a DOUBLE needs 4-byte alignment.
>
>
> Will it work for structures? Compare:
>
> Examples with padding:
> ---------------------
>
> xproto.xml:
>
>   <struct name="HOST">
>     <field type="CARD8" name="family" enum="Family" />
>     <pad bytes="1" />
>     <field type="CARD16" name="address_len" />
>     <list type="BYTE" name="address">
>       <fieldref>address_len</fieldref>
>     </list>
>     <!-- standard states padding here -->
>     <pad align="4"><sizeof>address</sizeof></pad>
>   </struct>

X11 protocol specification states:

HOST
  1                               family
  1                               unused
  2  n                            length of address
  n  LISTofBYTE                   address
  p                               unused, p=pad(n)

i.e 4-byte alignment. The natural alignment rules propose 2-byte
alignment here.

> sync.xml:
>
>   <struct name="SYSTEMCOUNTER">
>     <field type="COUNTER" name="counter" />
>     <field type="INT64" name="resolution" />
>     <field type="CARD16" name="name_len" />
>     <list type="char" name="name">
>       <fieldref>name_len</fieldref>
>     </list>
>     <!-- standard states padding here -->
>     <pad align="4">
>       <op op="+">
> 	<sizeof>name</sizeof>
> 	<value>2</value>
>       </op>
>     </pad>
>   </struct>
>
> xkb.xml:
>
>   <struct name="Listing">
>     <field name="flags" type="CARD16" />
>     <field name="length" type="CARD16" />
>     <list name="string" type="STRING8">
>       <fieldref>length</fieldref>
>     </list>
>     <!-- Spec states pad to a 2-byte boundary -->
>     <pad align="2"><sizeof>string</sizeof></pad>
>   </struct>
>
> The similar examples without padding
> ------------------------------------
>
> xv.xml:
>
>   <struct name="AttributeInfo">
>     <field type="CARD32" name="flags" mask="AttributeFlag" />
>     <field type="INT32" name="min" />
>     <field type="INT32" name="max" />
>     <field type="CARD32" name="size" />
>     <list type="char" name="name">
>        <fieldref>size</fieldref>
>     </list>
>   </struct>

Hm, source code of Xv says, that every "name" string is sent with 4-byte
allignment by X server.

>
> xkb.xml: STRING8 declared as char
>
>   <struct name="Property">
>     <field name="nameLength" type="CARD16" />
>     <list name="name" type="STRING8">
>       <fieldref>nameLength</fieldref>
>     </list>
>     <field name="valueLength" type="CARD16" />
>     <list name="value" type="STRING8">
>       <fieldref>valueLength</fieldref>
>     </list>
>   </struct>

I think it is error in specification. I compare Xkb spec with its
implementation. The fields of CARD16 type is padded with 4-byte
alignment. Does this break the initial natural alignment rule?

  <struct name="Property">
    <field name="nameLength" type="CARD16" />
    <list name="name" type="STRING8">
      <fieldref>nameLength</fieldref>
    </list>
    <pad align="4">
      <op op="+">
	<sizeof>name</sizeof>
	<value>2</value>
      </op>
    </pad>
    <field name="valueLength" type="CARD16" />
    <list name="value" type="STRING8">
      <fieldref>valueLength</fieldref>
    </list>
    <pad align="4">
      <op op="+">
	<sizeof>value</sizeof>
	<value>2</value>
      </op>
    </pad>
  </struct>


Some structures and requests have list of chars (1-byte member) is
padded with 4-byte alignment. The examples: 

Structures: SetupRequest, SetupFailed, Setup (however, they are not X11
requests and replies).

Requests: Connect (dri2.xml), QueryFilters (4-byte alignment before
"STR" structure), GetMonitor (xf86vidmode.xml). 

The rule can be changed to "every list with one byte member has size
that multiple of 4". I verify this for the lists of "char", "BYTE",
"void" and "CARD8". Too many files, I might miss something.