On 10/10/2010 03:50 PM, Bruno Haible wrote: > From this past experience, I estimate the risk of having a collision with a > system header by using a __ prefix as higher than the risk of having a > collision > with a user program by using a _ prefix.
That sounds like reasonable advice given your experience, thanks. However, it's not just __. From a Standard C point of view, all prefixes of the form _[_A-Z] are in the same category, so names like _FOO cannot be defined by user code, just as names like __foo and __FOO are disallowed. Also, all external identifiers beginning with _ must be avoided as well. These prohibitions have been in place since C89. C99 has also prohibited the use of all identifiers beginning with _ in file scope, in both the ordinary and tag name spaces. Hence any top-level struct in our code must have a tag that does not begin with _. This extra prohibition is not in C89, and I don't know of any C99 library implementation that takes advantage of it, but it's hard to imagine that the prohibition was added to C99 for no reason. This leaves us in a tight spot: except for member names, our files can't define useful identifiers that begin with _ without violating C99. On the other hand, our .h files do that regularly without serious problems, and it'd be quite a hassle to change all those names. Perhaps it'd help if we documented these naming issues in the gnulib manual somewhere. I doubt whether we can come up with strict rules that will keep everybody happy and are guaranteed to work everywhere, but it wouldn't hurt to at least document the issues. I should also mention that when it comes to time.h we are already violating the C Standard, as the standard prohibits an application from including its own header named "time.h". But there's not much we can do about _that_, other than document it.
