[Xcb] Xevent and XCBEvent

[Jamey Sharp]

On Sun, 2005-05-22 at 17:52 -0700, Josh Triplett wrote:
> Jamey Sharp wrote:
> > On Sat, 2005-05-07 at 09:00 +0200, Vincent Torri wrote:
> >>In a function of ecore, an XEvent is defined as follows :
> >>
> >>1) How could I fill the char event[32] that I have to pass to XCBSendEvent
> >>with these informations ?
> 
> Hmmm.  I was going to suggest that you should create an
> XCBClientMessageEvent and then pass the address to XCBSendEvent, but I
> just realized that XCBSendEvent always assumes the client buffer is 32
> bytes long, and will therefore read data past the end of the array if
> attempting to send an event which is less than 32 bytes long.
> XCBClientMessageEvent has data out to 32 bytes, but other events don't.
> 
> Any suggestions, Jamey?  Having to create a 32-byte array and copy the
> data in is really ugly; even uglier is creating a 32-byte (or 8-dword
> for alignment) array, casting the pointer to an XCBSomethingEvent, and
> setting the members that way.  Padding every single event structure out
> to 32 bytes seems highly suboptimal as well.

And, on the other hand, asking XCB to allocate enough zeros to writev as
padding doesn't seem so great either. (Though I've been thinking there
would be some benefit to allowing a null pointer in a 'struct iovec'
passed to XCBSendRequest to be replaced by an array of zero bytes, with
appropriate length.)

The traditional solution, of course, is a union of, say, CARD32[8] and
XCBSomethingEvent. That's still ugly.

I think the approach I like best is auto-generating the trailing padding
for events and errors, but the problem is that requires knowledge of the
unpadded size of the structure.

It turns out that gcc 3.3.5 (at least) will happily compile declarations
like this one, even with -Wall -pedantic -ansi, and even produce
reasonable results:

char buf[32 - sizeof(struct { int a; float b; char c; double d; })];

So an extra pad field could be produced in that manner by re-emitting
the entire structure inside sizeof.

> This is now fixed:
> >   <union name="ClientMessageData">
> >     <!-- The format member of the ClientMessage event determines which array
> >          to use. -->
> >     <list type="CARD8"  name="data8" ><value>20</value></list> <!--  8 -->
> >     <list type="CARD16" name="data16"><value>10</value></list> <!-- 16 -->
> >     <list type="CARD32" name="data32"><value>5</value></list>  <!-- 32 -->
> >   </union>
> > 
> >   <event name="ClientMessage" number="33">
> >     <field type="CARD8" name="format" /> <!-- 8, 16, or 32. -->
> >     <field type="WINDOW" name="window" />
> >     <field type="ATOM" name="type" />
> >     <field type="ClientMessageData" name="data" />
> >   </event>
> 
> Note that this was only easy because the lists are fixed-length.

I saw the commit message for this go by. This is cool: thanks!

--Jamey