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

[Ran Benita]

Hi Uli,

Sorry for the late reply - I see you already made the first release
(nice!) but anyway, for the archives..

On Sun, Apr 05, 2015 at 03:01:58PM +0200, Uli Schlachter wrote:
> >> 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.

So, maybe this implies that the right strategy is put the error data of
each extension inside of its .so? That can only work if the library is
tightly integrated as a part of libxcb of course.

The reason I think it's better to integrate with libxcb is that adding a
dep always brings some friction, and it'd be cool if support for nice
error messages come built-in.

Separating has some advantages, like
- Fewer bytes in libxcb (insignificant I think),
- Can be released/maintained separately,
- Can be used with older libxcb versions (=> can be bundled easily),
- Don't have to deal with libxcb complexities.

Well the burden falls on you and the release is done so this is moot :)

> >>> 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...

Yea, that seems fine.

Ran