Naming

Tim McDaniel mcdaniel at amara.uucp
Thu Mar 1 05:03:47 AEST 1990


gwyn at 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 at mailgw.cc.umich.edu
UUCP: {uunet,sharkey}!amara!mcdaniel



More information about the Comp.std.c mailing list