Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: problem with cc compiler
Message-ID: <10599@smoke.BRL.MIL>
Date: 24 Jul 89 22:00:55 GMT
References: <712@unsvax.NEVADA.EDU> <10589@smoke.BRL.MIL> <1185@fcs280s.ncifcrf.gov> <10594@smoke.BRL.MIL> <4935@alvin.mcnc.org>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 28

In article <4935@alvin.mcnc.org> spl@mcnc.org.UUCP (Steve Lamont) writes:
>Suppose that I wish to implement my own math library function, say sin() or
>cos(), for whatever reason, in a large pre-existing piece of code that I don't
>want to fiddle too much with.  How would I do this, then?

Since it is unlikely that any non-math function in the C library would
invoke cos() or sin(), you might be able to get away with simply providing
your own, but it is not guaranteed to be portable to do so.

Much better would be for you to name your functions my_cos() and my_sin(),
and include something like the following in your application header file:
	#undef cos	/* in case <math.h> uses a #define cos $$COS etc. */
	#define	cos	my_cos
	#undef sin
	#define	sin	my_sin

Then include your application header file AFTER <math.h> in your sources.

>Also, what provision is there for overriding this stricture, if, for instance,
>I am assigned the task of rebuilding a standard library?  Is the compiler
>going to refuse to let me write my own read() function then, too?

It all depends on the implementation.  The (conforming) compiler is never
going to refuse to allow you to write a read() function; it may refuse to
allow you to write a __read() function, however, since that's in the
implementation's reserved name space.  In practice I don't expect compilers
to be so constraining, because probably the same compiler is used to build
the C library as is used for application programs.