[Xcb] Naming standard for X error constants
Ian Osgood
iano at quirkster.com
Mon Nov 12 17:11:23 PST 2007
On Nov 12, 2007, at 4:33 PM, Barton C Massey wrote:
> In message <08385FA5-2003-492D-AE7D-ECAD1AA55864 at quirkster.com> you
> wrote:
>> Jamey reverted the experimental patch to qualify error constants with
>> XCB_BAD_*, because some of the extensions were already doing this
>> work by hand, resulting in XCB_BAD_BAD_* for their errors. (I don't
>> know why Jamey didn't just fix the extensions.) I would like to
>> figure out how to qualify error constants once and for all before we
>> make another release.
>>
>> My next proposal is to qualify errors by appending *_ERROR. Can
>> anyone think of a reason this would not work or otherwise be hard to
>> implement?
>>
>> Really, I don't see how we could recommend XCB for production code
>> (which unlike demo code, does strict error checking) until we
>> finalize this. In my opinion, it is not feasible to leave the error
>> constants unqualified as they are.
>
> I think it would be feasible to leave things as they are,
> although it may be undesirable. I am uncomfortable with any
> proposal that just goes around slapping prefixes or suffixes
> on constants clearly named in the protocol documentation; at
> the very least I think this requires forking a copy of the
> protocol document and updating it to the new names.
>
> Actually, I'd be pretty comfortable with the idea of us
> taking over the protocol document anyway, and I doubt anyone
> would fight us over it much :-). What we really need is a
> document-master who will gather up all the protocol and
> extension source documents, get them into a common format
> and coherent form, and then maintain changes to them as
> needed. Note that I'm not volunteering for this :-).
>
> Failing that, I think I'd support something more limited to
> address our current problems; alias the core errors to
> XCB_BAD_* as per common practice and leave the extension
> authors to figure out what they want to do on a
> per-extension basis.
>
> Bart
We are already diverging from the protocol document. There are a
handful of symbols whose names clashed and were renamed because the
error symbols are unqualified. I just want to avoid giving the error
symbols primacy, since they are certainly not the most important
symbols in the project (in fact, I doubt any of us on the XCB project
have ever used them).
Perhaps this is no longer a problem after the Great Renaming, since
we divided CONSTANTS from types_t from functions using a combination
of case sensitivity and suffixes. However, we did not go back to
clean up the aforementioned name conflicts. I just think we should
do a fine-combed review before we make any further releases.
Ian
More information about the Xcb
mailing list