Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!brutus.cs.uiuc.edu!uakari.primate.wisc.edu!aplcen!haven!ncifcrf!nlm-mcs!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: Naming
Message-ID: <12246@smoke.BRL.MIL>
Date: 27 Feb 90 19:48:27 GMT
References: <MCDANIEL.90Feb20172440@orenda.amara.uucp> <1990Feb23.184656.3110@siia.mv.com> <16021@haddock.ima.isc.com> <MCDANIEL.90Feb27103334@amara.amara.uucp>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 14

In article <MCDANIEL.90Feb27103334@amara.amara.uucp> mcdaniel@amara.uucp (Tim McDaniel) writes:
>Are standard library names utterly and completely reserved, or can I
>fake it with #define, as in
>	#define malloc(bytes)	my_malloc(bytes, __FILE__, __LINE__)

You may #define your own malloc macro only if you don't #include <stdlib.h>.
However, C library functions that need to allocate storage may invoke the
real malloc() library function to do so; consequently your my_malloc()
implementation had better not interfere with the standard malloc().  The
usual way to guarantee this would be for my_malloc() to obtain its own
memory pool via malloc() and reallocate portions of it according to its
own notions.

It would be better to use some name other than malloc for this macro.