Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!nrl-cmf!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: Machine specific predefined names
Message-ID: <7276@brl-smoke.ARPA>
Date: 18 Feb 88 21:58:31 GMT
References: <1988Feb17.115402.12739@light.uucp>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Distribution: na
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 31

In article <1988Feb17.115402.12739@light.uucp> bvs@light.UUCP (Bakul Shah) writes:
>1) Is our local expert right?

Yes.

>2) If so, will companies such as SUN, AT&T, DEC etc. predefine
>   names such as _Sparc, _U3b2, _Vax in their ANSII C compilers?

Possibly they will, or maybe they could get together and decide
on how to register the values of unofficial standard vendor macros
such as __CPU__, __OS__, etc. (which don't yet exist!)  This would
be useful, but was outside the scope of X3J11.

>If the compiler vendor provides a system call library, is
>it considered part of an implementation?  If so, will the system
>calls have to be _Renamed?

No, here's the situation.  The C library can contain all sorts of
vendor-specific stuff, POSIX additions, etc..  However, since
all normal (non leading-underscore) external names not named in
the [proposed] standard are guaranteed to be available for use by
applications, none of the implementations of library functions
named in the ANSI C standard is allowed to refer to such an extra
external name, nor to any other external name that could cause
linking with a module containing such an extension.  This means
that virtually all existing C libraries will need to be revised
so that, for example, fopen() does not call open() but instead
calls _open(), for example, where "_open" is not tied to "open"
in the library.  There can be a separate module in the library
containing "open" (which could just branch to _open), however,
so long as the ANSI C implementation does not depend on it.