Since I was asked about evil_malloc() -- the main reason I introduced it was that malloc debuggers (e.g. Electric Fence) don't like malloc(0), and I wanted to be able to use them.
The reason is that malloc(0) is not required to return NULL; all that is required is that it return a pointer which can be free()d -- this can introduce some subtle bugs depending on the platform and libc versions.
[ regrettably, realloc(p, 0) is not guaranteed to return NULL either, though it is more likely to :/ ]
While I don't see any harm to livarot specifically resulting from differing malloc(0) behaviors, there is far too much code in there that is "wrong, but harmless". I want rid of it; subtle bugs cropping up in livarot is sapping far too much of my development time.
So, anyway, the proper resolution to the evil_malloc() business is to replace the calls to evil_malloc() with an explicit check of the allocation size (really, nrPt or whatever the size is computed from).
I will do that myself eventually, but it's a simple enough task that anyone can do it if they are so inclined.
-mental
References:
http://sources.redhat.com/ml/libc-hacker/1998-06/msg00001.html
http://users.bestweb.net/~ctips/tip028.html
http://lists.freebsd.org/pipermail/freebsd-standards/2004-February/000395.ht...
http://www.ussg.iu.edu/hypermail/linux/kernel/0011.0/1122.html
http://www.uclibc.org/downloads/Glibc_vs_uClibc_Differences.txt (item #4)