[Xcb] Padding in the XML protocol descriptions
Barton C Massey
bart at cs.pdx.edu
Mon Dec 29 11:36:25 PST 2008
In message <694519c50812262311n53f916a5m968935df2f8712b3 at mail.gmail.com> you wrote:
> I'm still slowly working on a Haskell port of XCB, generated from the
> xproto XML files.
Cool.
> After reading through xevie.xml, I realized that padding in declared
> structures seems to have two meanings when used in the protocol
> descriptions:
>
> 1) Filer - the most common case, this seems to be mostly for alignment
> and protocol regularity
>
> 2) Unknown Data - In the struct xevie.Event, we have 24 bytes of
> padding that are intended to carry unknown data
This is a bug in the xevie XML. If bytes are intended to
carry data, they aren't padding.
> I only knew about the first use when writing my own processors of the
> XML data, so I ignored all padding except when serializing and
> deserializing structures.
>
> Now I'm faced with muddying up all of my data types with extra fields
> because I don't know when the padding is meaningful, and I need create
> unique names for all of the ocurances of padding in a given data
> structure.
Padding should never be meaningful.
> Is there something we could use instead of padding when it's supposed
> to cary meaning? Like a char array? The XML specs are C-focused, and
> I don't know what's idiomatic for C in these cases.
IMHO, use a LIST of CARD8 in these situations. We'll take
patches to the protocol descriptions.
In the case of xevie, it is deprecated and has been removed
in the latest Xorg server release, so it doesn't much matter
what you do---folks shouldn't be using it.
Should we have a deprecation mechanism for retaining
protocol descriptions like xevie and xprint but marking them
such that they aren't built by default and generate
appropriate warnings? If so, how should this look exactly?
Bart
More information about the Xcb
mailing list