[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