Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!milano!uudell!loft386!dsuvax!ghelmer From: ghelmer@dsuvax.uucp (Guy Helmer) Newsgroups: comp.std.c Subject: Re: Naming Message-ID: <1990Mar1.161900.16556@dsuvax.uucp> Date: 1 Mar 90 16:19:00 GMT References: Organization: Dakota State University Lines: 42 In article , 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 . > ... > 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