Nix wrote:
> Um, `reserved for use as {X}...' means `you cannot use them as {X}
> because they are reserved, but you can use them for other things'.
>
> Note the phrasing of the previous clause, which reserves
> e.g. identifiers beginning with underscores and uppercase letters `for
> any use'; that doesn't mean you can use them for anything at all, it
> means you *can't*.
No, the common meaning of "reserved for X" means that it is kept for the
exclusive use of X. When a table at a restaurant is reserved for the
Smith party at 11, only members of the Smith part get to use it at 11.
It does not mean that Smith will not be allowed to use that table at 11
because it is reserved.
But you don't have to rely on common meanings, the Standard goes on to
state explicitly what it means by "reserved for X".
After listing what the various classes of identifiers are "reserved for"
it then defines what to do with all of them in the following paragraph
that explains what the lists are all about:
"Applications shall not declare or define identifiers with the same name
as an identifier reserved in the same context."
The meaning of the "reserved for" in the previous paragraphs is to
define the "context" for those identifiers.
So if the C compiler implementation defines __FOO as an external
function (which they are allowed to do because such identifiers are
reserved for any use) then an application is not allowed to define __FOO
because there will be a conflict.
Since you have no way of knowing which function names a compiler
implementation will use, that means that you as an application developer
had better not name anything __FOO, so only compiler implementors get to
use names like that. They can use those names without fear of collision
with application developers.
If you as an application developer want to use a name like _foo you are
allowed to use it as a file local identifier as long as it is not
already being used as a file local identifier, for example in a system
header that you include. Since there would be no way for you to know
about arbitrary macros and function names with file scope defined by
compiler implementors in their system header files, in practice that
means that compiler implementors cannot use names such as _foo as file
local identifiers. That is so you can choose _foo as the name for a
static function and not be concerned about a name collision.
The examples you gave from glibc are all declared external. That is a
different "context" than the local file scope for which those
identifiers are reserved. Thus an application can define identifiers
with the same name as long as they are file local.
That even makes sense: You can define a static function named
_dl_mcount_wrapper_check in a file and not worry about a name collision
unless you are writing something that actually explicitly uses that
external function. If the glibc developers had used
_dl_mcount_wrapper_check as a file local identifier, then you would have
to worry about it. The effect of the rules is that the glibc developers
know to stay away from using _foo as a file local name in system headers
and application developers know to use _foo for that purpose.
-- sidney
