[Xcb] size annotations for XML-XCB, and other tools

Jeremy A. Kolb jkolb at brandeis.edu
Thu Jun 15 11:10:30 PDT 2006


On Thu, 15 Jun 2006, Jamey Sharp wrote:

> On Thu, Jun 15, 2006 at 11:01:04AM -0400, Jeremy A. Kolb wrote:
> > I don't this seems to take into account the padding at the 
> > end of requests/replies when not explicitly marked.
> 
> True. In fact it doesn't automatically compute padding at all, yet, or
> the size of requests/replies. The latter addresses your concern most
> directly: it doesn't do it at all so it can't be doing it wrong. :-)
> 
> Note that a fair amount of padding can't be automatically computed, as
> far as I can tell, though some of it can. <pad bytes="5" /> appears once
> or twice even though natural alignment only requires <pad bytes="1" />.
> 

There are quite a few extension docs that list padding as an expression, I 
guess that doesn't really help here though.

> Also, the large padding before <list>s in replies is, I think, not a
> hard requirement so some extension might omit it eventually. Although
> since none currently does, I guess I should auto-generate that padding
> and we can add a <reply pad-end="false"> attribute or something later.
> 

How do you mean 'not a hard requirement'?  Do you mean in the design?  
Because if you remove the padded bytes those replies will not be 
accurate.


> On the other hand, with this size information we can eliminate all those
> <pad bytes="1" /> tags at the beginning of the core requests.
> 

> > Are we going to do the Xlib thing where each req/rep is going to have a 
> > #defined size?  Would that be useful?
> 
> No. In C, we have sizeof(). :-)
> 
> This annotation is so that code generators (in particular, c-client.xsl)
> can do a better job. I think it's unlikely the computed sizes will wind
> up in the generated code verbatim, except maybe in trivial cases where
> it doesn't matter.
> 
> --Jamey
> 

Jeremy



More information about the Xcb mailing list