This is the mail archive of the
glibc-linux@ricardo.ecn.wfu.edu
mailing list for the glibc project.
Re: Namespace pollution?
- To: glibc-linux at ricardo dot ecn dot wfu dot edu
- Subject: Re: Namespace pollution?
- From: Kaz Kylheku <kaz at ashi dot footprints dot net>
- Date: Thu, 4 Nov 1999 17:41:04 -0800 (PST)
- Reply-To: glibc-linux at ricardo dot ecn dot wfu dot edu
On Thu, 4 Nov 1999, Martin v. Loewis wrote:
> > Wow, this is a real interesting discrepncy between the API atandards
> > and the ABI spec.
> >
>
> Not really. It says "identifiers with file scope", i.e. functions and
> variables declared "static", and macros. I think this goes beyond the
Not macros. Macros don't have file scope. Also, static doesn't have anything
to do with it. An external declaration simply appears outside of any function
body or prototype declaration. Typedefs and struct/enum/union tags created
outside of a function have file scope too, but no linkage.
> > The SYSV ABI
> > http://www.sco.com/developer/devspecs/gabi41.pdf
> > Page 6-3 System Service Synonyms
> > ...
> > name This gives the traditional name, such as read.
> > _name This gives a system service name that follows the ANSI C
> > convention of reserving symbols beginning with an underscore, such
> > as _read.
> >
> > a contradiction??
>
> Given my interpretation of the Posix/Unix rules, I'd say that this ABI
> definition reserves names that are still available to the application
> according to Posix.
In what context does it reserve them? The names are only available to the
application in some contexts; as the names of statement labels, or names
used in block-scope declarations. If the reservation delves into this freedom,
it's indeed more restrictive.