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

[Uli Schlachter]

Hi,

Am 26.04.2015 um 22:33 schrieb Ran Benita:
[...]
>>>>> 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 :)
[...]

I do like the idea, but it might be hard to implement.

This would require changing xcb_prefetch_extension_data() and
xcb_get_extension_data() to also save this list of errors etc. However, these
functions just get an xcb_extension_t*. That struct is part of the public API,
cannot be changed and contains just a const char *name and and int global_id
(initialized to 0 and cannot really be (ab)used).

Since xcb_get_extension_data() is called by user code.. well, I don't see how
this could be modified to take extra arguments in an ABI and API compatible way.

Sorry,
Uli
-- 
Bruce Schneier can read and understand Perl programs.