[Xcb] [PATCH] XCB-XML: Proposal for alignment padding

[Evgeny M. Zubok]

Jamey Sharp <jamey at minilop.net> writes:

> I'm really late on this thread. Just wanted to throw in these opinions:
>
> - I'm with Julien that in general "I'd rather have that work done in the
>   code generator than in the xml description, to keep that as readable
>   as possible (and incidentally, avoid introducing new bugs there)."
>   
> - On the other hand, code generators ought to be simple to write too.

> Together, those suggest to me that we should have a separate tool that
> pre-processes the XML-XCB protocol descriptions to add any annotations
> we know how to automatically compute. It was for reasons like this that
> I wrote proto/src/size.py and friends.

> A little constant-folding should be able to compute a simplest
> expression that correctly specifies length of the request-so-far, modulo
> the alignment needed.

> And since every type has a natural alignment, we can compute the minimum
> padding required before every field, and minimum required at the end of
> a request or response. I tend to believe that the original protocol
> descriptions should only contain <pad> elements when the protocol
> requires more than minimum padding.

There are cases when the alignment actually is *not* required but will
be added by that rule. I've showed the example of such request -
SetCrtcGamma from randr.xml. The algorithm in quote above will not able
to deduce that the pads between lists of CARD16 are not needed; it will
always insert the alignment code between them. The bug with erroneous
alignments in xcb_randr_set_crtc_gamma already exists (Julien seems to
agree). A hint about either presence or absence of padding for code
generator must be provided in XML description. The same requests/replies
can be found in xkb.xml. My solution is to specify padding when it's
necessary.

Suggested rule "(length of the request-so-far) modulo 4" needs strong
verification. Probably, the X11 protocol designers were considering this
rule, when they were specifying the protocol encoding, however, the X11
specification states the paddings only as "(some expression) modulo
N". We must ensure the equivalence of both rules for all requests and
replies. The equivalence is not obvious but, more probably, is virtually
true. If the rule "(length of the request-so-far) modulo 4" will be
proven true for all requests, replies and structures, then we will be
able to omit <expression> from <pad> and even 'align' attribute will
become redundant. However, the expression in the pad declaration greatly
simplifies the code generator, eliminating the size analysis from the
generation process.

In the current implementation of code generator, the aligment is
calculated by another rule: "(length of the previous field) modulo
4".

Don't forget about structures. Incorrect padding leads to the bugs in
iterators. For example, there is bug (I guess) in
xcb_sync_systemcounter_next (sync.c); it doesn't take into account the
padding after the list "name". One may think that a solution would be to
add padding implicitly after every list of chars. However, the solution
is not common. There are the structures that don't require padding after
the list of chars (for example, structure STR from xproto.xml or
AttributeInfo from xv.xml, etc). XML pre-processor will not able to
deduce the presence or absence of padding.

WBR, Evgeny M. Zubok