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

Ran Benita ran234 at gmail.com
Mon Mar 30 17:02:09 PDT 2015


On Mon, Mar 30, 2015 at 04:06:39PM +0200, Uli Schlachter wrote:
> >I see that you generate extensions.c during build. Have you considered
> >commiting it to git instead? That way all versions are the same, and do
> >not depend on the builder's environment. If there's a change you can
> >release a new version. (I'm not arguing for that - just a
> >consideration).
> 
> Generated code doesn't belong into git. :-P

I'm not dogmatic about that. But that part of my comment was slightly
confused; if the generated output is a pure function of the xcb/proto
xmls then I don't see a problem with generating it every time (when I
wrote it I mixed up the dynamic stuff).

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

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

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

Ran


More information about the Xcb mailing list