Paul Eggert wrote: > > But why use __ as prefix? Symbols starting with __ are, generally speaking, > > in the territory of the implementation (libc + compiler), which is why > > gnulib > > tries to use only symbols that start with a single _. > > But this symbol will appear in <time.h>, so it has both flavors: from > gnulib's point of view it is a user symbol, but from the gnulib-using > application's point of view it appears in a Standard C header. I can > see both points of view and am not sure which should prevail.
Yes, gnulib is in the middle. gnulib has been happily using _ prefixed symbols for years (all kinds of _GL* but also _UNUSED_PARAMETER_ and others), and never encountered a conflict. Whereas when gnulib / libintl had to define a function named '__printf__' it was quite troublesome, and when we tried to define a function named __fpurge, we also encountered a collision with a system. And we had collisions with __restrict as well. 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. Bruno
