Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!yale!umich!sharkey!amara!mcdaniel
From: mcdaniel@amara.uucp (Tim McDaniel)
Newsgroups: comp.std.c
Subject: Re: Naming
Message-ID: <MCDANIEL.90Feb28130347@amara.amara.uucp>
Date: 28 Feb 90 18:03:47 GMT
References: <MCDANIEL.90Feb20172440@orenda.amara.uucp>
	<1990Feb23.184656.3110@siia.mv.com> <16021@haddock.ima.isc.com>
	<MCDANIEL.90Feb27103334@amara.amara.uucp> <12246@smoke.BRL.MIL>
Sender: mcdaniel@amara.UUCP
Organization: Applied Dynamics Int'l.
Lines: 34
In-reply-to: gwyn@smoke.BRL.MIL's message of 27 Feb 90 19:48:27 GMT

gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
   You may #define your own malloc macro only if you don't #include <stdlib.h>.
   ...
   It would be better to use some name other than malloc for this macro.

Suppose I just want to put a wrapper around a system function.  For
instance, free given a NULL argument could just do nothing (if my
system's supplied free would abort in such a circumstance).  Or
suppose I'd like to record a stack trace.

In such a case, I would like to just do
    extern void * my_malloc(size_t);
    #undef malloc
    #define malloc(x) my_malloc(x)
where my_malloc does wrapperish stuff and then calls the real malloc
to do the real work.  I'd set up "my_stdlib.h" with such declarations.

So, if I ever #include <stdlib.h>, even if I #undef malloc as a
precaution, I can't #define a new malloc?  That's a bummer.  (By using
a my_stdlib.h, there's a workaround, but it's still an annoyance.)

I assume the reasoning is that the compiler might have, say, malloc()
as a builtin, enabled upon seeing
    #include <stdlib.h>
However, it would have been easy to mandate that there be a way to
turn it off, say via
    #undef malloc
after the #include.  Oh well, too late now.

--
Tim McDaniel
Applied Dynamics International, Ann Arbor, MI
Internet: mcdaniel%amara.uucp@mailgw.cc.umich.edu
UUCP: {uunet,sharkey}!amara!mcdaniel