[Xcb] [RFC] New project: util-errors for translating numbers into request/error/event names

[Uli Schlachter]

Hi again,

I went through Ran's suggestions and I think implemented all of them except for
one (see below).

New API since last time:

- xcb_errors_get_name_for_xge_event()
- xcb_errors_get_name_for_xcb_event() (accepts an xcb_generic_event_t* and
figures out the correct type)
- Functions where it made sense have a new last argument const char **extension
which gets set to NULL or the extension that the request/error/event belongs to.

Does anyone have a better idea for the name of this library? The idea came from
pretty-printing errors, but it also handles events and requests (and events
really are the most complicated part of this)...

[...]
>> Generated code doesn't belong into git. :-P
>>
>> However, I could think about having "make dist" include it into the release.
>> I'm not convinced if that is a good idea, since I expected this code to
>> change rarely (and thus rarely have new releases), but xcb-proto might
>> "often" be enhanced with new extensions... On the other hand, which distro
>> will rebuild the library for newer xcb-proto versions?
> 
> Right - the code will probably never change but xcb/proto will. For
> libxcb that kinda works because the releases are synced. But here it
> probably won't.
> 
> Why not integrate this to libxcb then? Seems suitable to me.

What do others think about this? libxcb.so itself currently doesn't contain any
generated code, only the extensions itself do. Also, if the only reason for this
is to force distros to recompile this library for newer xcb-proto releases, then
that's a bad reason IMO.

>>> Is it not possible to make it entirely static? (i.e. no memory
>>> allocations / requests at all). (Are first_event/first_error dynamic?)
>>
>> Nope, first_event and first_error are dynamically assigned by the X11 server.
> 
> OK. If it is not possible to make things static (or it makes the API too
> cumbersome) have you considered using the XCB extension cache (i.e.
> xcb_get_extension_data(), xcb_prefetch_extension_data()) instead of
> using all of the xcb_query_extension()'s' directly? Don't know if
> there's some to be gained by that.
> 
> (Actually that would require linking xcb-* in, so probably no-go
> anyway).

Yeah, the linking makes it difficult / impossible to re-use XCB's cache.

>>> Finally, I think a library whose purpose is informative errors should
>>> itself return informative errors :) Maybe <errno.h> codes?
>>
>> You mean returning -ENOMEM when calloc() fails?
>> The only other possible error would be "some X11 request failed" and I don't
>> know which error code to use for this. I'll think about it.
> 
> You can make up your own codes. Well most people will ignore the error
> code anyway - I just couldn't help mentioning it :).

The only possible errors are "calloc() failed" and "xcb_query_extension_reply()
returned NULL (aka: connection is in error state)" and both of them will break
things elsewhere. Also, I failed to come up with errno codes which would result
in useful error message. Does it really make sense to define my own error codes
for these two cases? What if more than one error occurs?

If you are really paranoid, you can set errno=0 and check
xcb_connection_has_error() afterwards. If errno is ENOMEM afterwards or the
connection is in an error state, we know what happened...


As far as I can see, this library is pretty much finished. If no issues show up
and no one complains, I will upload this to freedesktop as an XCB project and do
a 1.0 release.

Any Objections or comments?

Cheers,
Uli
-- 
99 little bugs in the code
99 little bugs in the code
Take one down, patch it around
117 little bugs in the code
  -- @irqed