Paul Eggert <[email protected]> writes: > On 2026-03-08 06:26, Bruno Haible via Gnulib discussion list wrote: >> Please don't use identifiers that start with '__gl'. Identifiers that >> start with '__' belong to the system (= compiler + libc). > > I was a little disappointed to see patches immediately installed to > implement this request even though I've recently written here that I > disagree with it at least in part. > > Gnulib is supposed to help its users, not get in their way. So when > Gnulib is implementing a standard C or POSIX header, it should be > viewed as being part of the implementation not part of the > application, and its API strive to follow the relevant namespace > rules. > > Yes, this places a greater burden on the Gnulib developers, as it > means we must pick names like "__gl_whatever" that work on every > practical Gnulib target. But that's OK: it's better for us to take on > the minor burden of picking such names, than for users of Gnulib to > take on the burden of worrying about Gnulib's intrusion into their > namespace. > > So as a compromise I propose that although it's fine to stick with > ordinary names when implementing Gnulib's own headers, we should avoid > this when implementing standard headers.
I thought the "__gl_*" naming convention was okay to use as well. I'm not particularly worried about applications using either the "_gl_*" or "__gl_*", but I do feel a bit more safe using "__gl_*". Most applications will avoid the double prefix prefix entirely since it is reserved for the system. I'm not really worried about systems or libc implementations using "__gl_*" either. Certainly glibc knows to avoid it. That is the same reason I am okay with names like "gl_set_t" which is under the "*_t" namespace reserved by POSIX. It is technically violating namespace rules, but in practice POSIX will never use a name like that. Collin
