From: jy10033@ehsn11.cen.uiuc.edu (Joshua M Yelon) Subject: Re: malloc (0) ( Re: function-->macro bugs.) Date: Sat, 21 Nov 1992 18:38:12 GMT
Well, recent discussion has revealed that it IS correct (according
to POSIX) to turn malloc into a macro. (I had asserted the opposite).
On the other hand, this behavior is clearly breaking a lot of
programs. Many programmers seem to assume that a function is a
function, not a macro. According to POSIX, that assumption is
wrong... but on the other hand, it _is_ a natural assumption, and one
that is supported by other operating systems. Perhaps we should treat
it as a 'de-facto standard' - not written into POSIX, but something
that programmers frequently and intuitively rely upon, and therefore
worth supporting...
On a separate note:
Here's another possible solution to the MALLOC problem:
#ifdef FIX_MALLOC
static inline void *malloc(n)
size_t n; /* thanks Lars :-) */
{
return __fixed_malloc(n);
}
#endif
Lars says that that's formally incorrect... but in practice, it works fine,
and it doesn't break this:
void *malloc();
or this:
void (*allocator)() = malloc;
it does break this:
/* my super-fast allocator */
void *malloc(n)
...
but only if you explicitly put FIX_MALLOC in the program.
So that's a "2 1/2 out of 3" solution... anybody care to go for 3 out of 3?
Incidentally, notice that I used
#ifdef FIX_MALLOC
instead of
#ifndef NO_FIX_MALLOC
When I was compiling 'emacs', the "fix malloc" code confused it -
but emacs didn't ask for any malloc fixes! Neither did it need any.
The moral? Since "tricky fixes" like that one are ugly hacks, they
tend to be buggy, and they tend to break. It's better to leave
them OFF by default until you discover that you really need them.