Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!iuvax!purdue!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: problem with cc compiler
Message-ID: <10594@smoke.BRL.MIL>
Date: 24 Jul 89 03:15:15 GMT
References: <712@unsvax.NEVADA.EDU> <10589@smoke.BRL.MIL> <1185@fcs280s.ncifcrf.gov>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 30

In article <1185@fcs280s.ncifcrf.gov> kml@ncifcrf.gov (Kevin Lahey) writes:
>I just don't quite see how to insure that a regular function declaration
>doesn't override a library function.  Assuming that this magic system works
>(I don't doubt that it does), how can one override a library function when
>desired?

A standard-conforming implementation is not allowed to call functions
other than those specified as being in the standard library and others
(primarily with names beginning with underscore) that are specifically
reserved for the implementation by the Standard.  read() is an example
of a function that a conforming C implementation must permit applications
to use for their own purposes.

A strictly conforming program is not allowed to provide its own version
of any of the standard library functions.  Primarily this is because
such a substitution may well break the implementation, especially when
there are internal implementation constraints of which the application
programmer is unaware.  (It does happen.)  read(), however, is not a
standard C library function, although in an IEEE 1003.1 environment
read() is assumed to be available from the library.  Implementations
that are simultaneously ANSI C and IEEE 1003.1 conforming will provide
read() in their C library, but will invoke a different name such as
_read() from within their stdio functions or use some other similar
scheme to avoid calling a user-provided read() function.

If you were designing a language from scratch, there would be much
better means available to avoid name collision.  Ada "packages" are an
example of such a mechanism.  However, we're stuck with C as it has
historically evolved, and the proposed Standard has gone about as far
as feasible in this direction.