Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!ncsuvx!ece-csc!mcnc!rti!sas!bts
From: bts@sas.UUCP (Brian T. Schellenberger)
Newsgroups: comp.lang.c
Subject: Re: A tale of two C's.
Message-ID: <488@sas.UUCP>
Date: 2 May 88 04:55:34 GMT
References: <152@ghostwheel.UUCP> <7691@brl-smoke.ARPA> <154@ghostwheel.UUCP> <7750@brl-smoke.ARPA> <474@bnlux0.bnl.gov>
Reply-To: bts@sas.UUCP (Brian T. Schellenberger)
Organization: SAS Institute Inc, Cary NC
Lines: 33

There have been numerous postings back and forth about whether or not
one should replace library routines.  It seems to me to be much easier to get
the legitimate benifits of such replacement, assuming there are any, without
being unportable than most people seem to assume.

First of all, it is clearly unportable and dangerous to replace the versions
of the library routines used by other library routines, since there is no
way to know what the inter-relationships of these routines may be on various
machines.  This doesn't preclude you from doing whatever you want if the code
is for a single machine and single version of the compiler and operating 
system, but in such a case portable code (and the ANSI draft) should be of
no concern anyway.

Second of all, if you don't like the normal memory allocation routines, you
can write and use your own quite portably.

Third, if you *really* can't stand to change the name by which you call the
routines, it is pretty safe to 
	#define malloc  mymalloc

Of course, strictly speaking, the ANSI draft states that all library routine
names are reserved words, so this might be unportable (though I doubt it will
really fail anyplace).  So it would be safer to retrain your fingers to 
type "myalloc" instead of "malloc".  If you want it to be the same even on
machines whose native "malloc" you like, simply
	#if I_LIKE_IT
	#define myalloc malloc
	#endif
-- 
                                                         --Brian.
(Brian T. Schellenberger)				 ...!mcnc!rti!sas!bts

. . . now at 2400 baud, so maybe I'll stop bothering to flame long includes.