This is the mail archive of the
mailing list for the glibc project.
Re: use __prefixed symbols
- From: Roland McGrath <roland at frob dot com>
- To: Bruno Haible <bruno at clisp dot org>
- Cc: libc-alpha at sources dot redhat dot com
- Date: Mon, 26 Aug 2002 02:40:56 -0700
- Subject: Re: use __prefixed symbols
> Should function calls inside libc prefer the __ prefixed symbol aliases,
> or is this a non-issue?
It is not a non-issue, but it is a slightly subtle issue. It is a
non-issue for ELF dynamic linking with recent tools, because libc is made
to always resolve to its own symbols. The issue remains just as it has
always been for static linking, however. It would not hurt to always use
__ names, except inasmuch as it uglifies the code, and you need to watch
out for the source files that are also copied into other GNU packages to be
compiled outside of libc.
The reason for using the __ symbols is name space control. We need to
allow a standard-conformant program to use symbol names left in application
name space by the standard it conforms to, even if some other standard or
GNU extension defines conflicting symbol names. Ergo, a module linked in
to define symbols in a given standard we support must not refer to any
symbols without __ unless they are also specified by the same standard.
There is no need to use __ names for symbols that are specified by the same
standard (or implied set of standards). i.e., a GNU extension function can
refer to anything; a XPG function can refer to a 1003.1 function; a 1003.1
function can refer to an ISO C function. The full set of relationships can
be discerned from features.h (or the manual section about it).
> Here is the list of nonprefixed symbol calls I found.
All of those are fine just by the relationships of the standard name spaces
in question, except for:
> munmap -> __munmap
This was an actual problem (an ISO C99 or ANSI C89 program using stdio
could legally redefine munmap), but it was already fixed by the time I looked.