[Xcb] PATCH: XCBGenerateID segfaults if called with NULL

[Jamey Sharp]

On Sun, 2005-07-17 at 19:03 -0700, Travis Spencer wrote:
> I think I read on the Wiki somewhere or in the mailing list archive
> that XCB is built in a way that it puts the responsibility of
> validating input on the calling application.  If the application
> doesn't want to segfault, then make sure it never calls XCBGenerateID,
> for example, with a NULL XCBConnection pointer.  Am I remembering
> right?

Right. All XCB functions have an implicit precondition that the
XCBConnection pointer is not null, for example, and none should be
checking this.

> If I'm not, then XCBGenerateID will indeed segfault when given a NULL
> pointer.  The attached patch prevents this, and adds a comment about
> why a similar test isn't needed before using the return value of
> XCBXCMiscGetXIDRangeReply.

I don't understand the comment at all. That function absolutely can
return NULL, and never returns statically-allocated data. That's why
there's a call to free(3) once the values have been used.

> I'm not sure what XCBGenerateID is supposed to return on error; the
> XCB API document on the Wiki didn't say, and I could tell from the
> code.  So, I returned -1.

That's a fine question. I don't know what to do with error cases here:
everybody is going to expect XID allocation to never fail.

I guess -1 actually is an invalid XID since the most significant three
bits are not zero, which I believe is a requirement of the X protocol.
So -1 is probably the best available choice.

> Also, the whitespace in this file seems a little bit odd.  Its a mix of
> tabs and spaces.  What is the standard exactly?  Please say 1 hard tab
> of width 4 -- though I know you wont :(

Huh. You're right, the whitespace is broken on five lines of that file.

The convention in XCB, set for a number of bad reasons, is no tab
characters and four-space indents. In vim this corresponds to the sw=4
and et options.

--Jamey