Re: X server bug?

>> The bug is that, when a client issues a ChangeGC request trying to
>> set a clip-mask pixmap with 0x2000001a as the pixmap ID (not a valid
>> ID; X resource IDs never have any of the top three bits set), the
>> invalid ID value in the resulting error is 0 instead of 0x2000001a.
> I'm curious how you ran into this... some application that doesn't
> know the limits of resource IDs?

No.

I might as well mention it now; it's been sleeper-public for a year or
two and it'll go a bit more public in a couple of months anyway.

I've been building an X interface library - something that sits in the
same place in the software stack as Xlib or xcb - based heavily around
callbacks.  One of the things it does is to eliminate the way Xlib uses
protocol values for all the API defines.  To quote a comment:

 * Ideally, I'd like to set things up so that (to pick an example)
 *  LX_WCLASS is the type of a window class, with values such as
 *  LX_WCLASS_InputOutput and LX_WCLASS_InputOnly, and we get strict
 *  typechecking from the compiler, so that passing a non-LX_WCLASS_*
 *  value as an LX_WCLASS argument produces a type mismatch error.  But
 *  I also want LX_WCLASS_InputOutput and LX_WCLASS_InputOnly to be
 *  compile-time constants, so they are suitable for use in switches.
 *
 * I have not come up with a way to get both.  The compromise I'm
 *  picking is to use compile-time constant values and back off to
 *  run-time typechecking, by using values such that (for example)
 *  LX_WCLASS_InputOutput does not equal LX_BACKINGSTORE_WhenMapped,
 *  even though they have the same representation in the protocol, so,
 *  while it won't be a compile-time error to pass
 *  LX_BACKINGSTORE_WhenMapped as a window class, it will be a run-time
 *  error.
 *
 * This is especially relevant for values that are a set of fixed
 *  alternatives or an X ID, such as the input focus window (which is a
 *  window ID or None or PointerRoot).
 *
 * We can pick values which are known to be disjoint from X IDs because
 *  X IDs never have any of the 0xe0000000 bits set.

0x2000001a is LX_PIXMAP_None, which is the API value representing None
as a pixmap (as opposed to None as a window or None as a graphics
context or etc).  I obviously neglected to add code to map
LX_PIXMAP_None in the clip-mask setting to 0 on the wire (the protocol
spec says that None there is represented as 0), but the returned error
confused me because it was saying 0 was invalid, which it isn't; 0 is a
valid value for that field in the wire protocol.  It wasn't until I
snooped the wire protocol and saw it putting 2000001a on the wire that
I realized what I'd done wrong, then saw the 0 coming back in the error
event and realized what the server was doing wrong.

> I had to add #include <stdlib.h>,

Hm, yeah, I should write return(0) instead of exit(0) at the end.

> and I had to build with -lX11:

Well, sure; it's an X program.  (Admittedly, I probably should have
remarked on the need for -lX11.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email protected]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B