🚀 go-pugleaf

In article <MCDANIEL.90Feb28130347@amara.amara.uucp>, mcdaniel@amara.uucp (Tim McDaniel) writes:
> 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.

Yes.  Anyone other than the author might have a great time ( :-) ) deciphering
code written this way.

> Suppose I just want to put a wrapper around a system function.  [...]
> 
> 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.

The original purpose for this idea seemed to be to use the preprocessor
to put in calls to debugging code; if this is the case, why not write
something like:
     #ifdef DEBUG_ON
     #define MALLOC(x) my_malloc((x), __FILE__, __LINE__)
     #else
     #define MALLOC(x) malloc(x)
     #endif

If I were to read code written this way, I think I would understand
a thousand times faster what the author's intent was.  This also
avoids all the trouble with library routines defined as macros,
doesn't it?

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


-- 
Guy Helmer                              ...!uunet!loft386!dsuvax!ghelmer
Dakota State University Computing Services           helmer@sdnet.bitnet
Software Engineering: "'How to program if you cannot.'" - Dijkstra