Re: Namespace cleanliness and levels of indirection

[Roland McGrath]

> As I understand most internal functions and variables are prefixed with
> two underscores __. That is understandable for symbols lying in the
> global namespace. But why would it be necessary to prefix structure
> members and variables names of local scope with __  as well?

That is correct.  The reason for this in local symbols (macros, structure
members, etc) is so as not to be broken by e.g.:

#define lock ***lose***
#include <foobar.h>

If some struct in foobar.h uses `lock' as a member name, it is screwed.
ANSI C-1989 reserves all identifiers starting with `__' to the
implementation, so a conforming program can never do:

#define __lock ***lose***
#include <foobar.h>

The actual rules in ANSI C-1989 are more complex than that, and the rules
are different and less stringent in POSIX.1-1988 and further relaxed from
that in later POSIX standards.  But libc started using the `__' convention
universally around the time of the 1989 C standard and we have stuck to
that to keep it simple.

> Also I've noticed several ways of converting internal symbols into
> user visible ones. (a) Using a simple #define foo __foo, (b) using
> a level of indirection int foo() { return __foo(); }, (c) using
> weak_alias (__foo, foo). Which one of these is the preferred one?
> If more then one is commonly used, then what are the circumstances?

The standards allow any function to be a macro, so `#define foo __foo' is
often permissible strictly speaking.  But in practice it often winds up
being a nuisance to have done that, so it is not too common.  Sometimes we
use inline wrapper functions a la `inline int foo() { return __foo(); }';
that is important to do when __foo itself might be inlined.  The most
common thing we use for global symbols is weak_alias.

> Right now the code I have uses a mix of the above conventions. I would
> like to adopt a single one if possible. That would both simplify
> the code and render it more uniform.

I'm not sure it necessarily has to be more uniform than the existing libc
code base is in this regard.  Perhaps Ulrich has something to say about the
most desireable approach to take in new source code.