I’ve seen many places where
xfree() are used as replacements for the standard
free() functions (most of the time, to call
abort() or print debugging/log messages to some file.
The most recent example of these macros was the source of an HTTP proxy server.
My short comment to this sort of macros is:
If you feel inclined to add debugging and/or logging support to
free(), then BY ALL MEANS steer clearly and far away from such ugly “hacks”.
There are various reasons why using the C preprocessor to wrap
malloc() is silly and will turn around and bite you in the end:
- You do not really have any sort of control about what
malloc()function is called by already compiled, “object” code.
- You will probably have to resort to even more ugly preprocessor hacks to handle the portability aspects of this code. Some systems define their internal
malloc()function as void *malloc(size_t); others use int as the size argument; some may typedef size_t using compile-mode specific hacks (i.e. to support “large files” or a segmented memory model).
- You will probably miss some of the entry points to the system
malloc()code, i.e. the
posix_memalign()function; once you do, there are two possibilities: you will either print bogus traces/logs or you will misinterpret some of the traced data and consider it a bug—when, in reality, there is no bug in the allocator, but in the wrappers you wrote.
Before you embark on the “journey” of the
xwrapper() functions, make sure that you spend a considerable amount of time pondering the following:
Do you really think you can outsmart the platform vendor, who has spent a lot of time testing and verifying the system