[PATCH] Fix handling of SendEvent requests which set the SendEvent bit before sending the event down the wire
jamey at minilop.net
Tue Sep 13 08:38:23 PDT 2011
On Tue, Sep 13, 2011 at 07:31:12PM +0800, Sam Spilsbury wrote:
> I noticed that the server is not removing the SendEvent (0x80) bit in
> ProcSendEvent in dix/events.c before doing range checks on the event
> type. This would cause these range checks to return an invalid BadValue
> I am not sure if this is *really* a bug in the server or a bug in
> extension libraries (like libXext) who set the SendEvent bit before
> converting the event to wire format, since ProcSendEvent sets the
> SendEvent bit anyways just before it writes the event to the client.
To decide whose bug this is, I checked the X protocol specification. The
only relevant bit I found was this:
"The event code must be one of the core events or one of the
events defined by an extension ... The contents of the event are
otherwise unaltered and unchecked by the server except to force
on the most significant bit of the event code."
The first sentence suggests to me that this is a client bug, but the use
of "force on" in the second suggests that it's supposed to be OK if the
bit is on already.
Since it's clear what SendEvent should mean with the SendEvent bit set,
I'd be inclined to merge this patch. However, the client libraries
should also be fixed, for compatibility with existing X servers. Could
you put together a patch for any client libraries you've spotted with
> + if (stuff->event.u.u.type & 0x80)
> + stuff->event.u.u.type &= ~(0x80);
I think this would be more clear if you delete the "if" statement. Just
unconditionally mask off the SendEvent bit; if it already wasn't set,
the statement will just have no effect.
Still, either way:
Reviewed-by: Jamey Sharp <jamey at minilop.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the xorg-devel