Bye Bye mall##oc

Using malloc() and free() necessitates care; a lot of care. In fact, I can not remember seeing any non trivial C program, that would not have an extra memory management layer. Often a double linked list was involved and atexit() reporting of non free()ed memory. At the very least some simple reporting was going on usually redefining malloc() in terms of mall##oc(). I recently used the latter construct, to show off my superb arcane knowledge of the C pre processor, when I was met with skepticism; What was wrong with the LOC below?
To demonstrate (how little this PFY knew and) how cpp was going to balk at the recursive definition, I typed it in and, low and behold, the compiler accepted it and generated the right code. All I could do was grin. Of cause I had always realized that not adding a token to the symbol table before the whole definition was parsed would be better, but compilers just never did. Who changed this when? And would this open the door to recursive macro’s, does the pre processor do a multipass? So I ran the two snippets below through gcc -E to expand A(4).

Fail Redef
A(4)A(4 +1 +3) A(4)(4 +1 +3)

As you can see, there is some lazy expantion going on. If we RTFM, it shows that: Each macro is expanded when it appears in the definition of the other macro, but not when it indirectly appears in its own definition. Ok, I’ve learned never to trust things to stay the same, again.