From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius) Subject: Re: function-->macro bugs. Date: 21 Nov 1992 00:02:41 GMT
jy10033@ehsn11.cen.uiuc.edu (Joshua M Yelon) writes:
>Our "stdlib.h" does something unusual: it defines malloc as a macro.
>According to the standard, though, malloc is a function.
However, the standard also explicitly allows defining any function as
a macro as well, as long as the macro is well-behaving (evaluates its
arguments exactly once, and so on). It also specifies that the
functions have to be implemented as a macro as well. In order to make
certain that you get access to the function, do this:
#include <stdlib.h>
#undef malloc
>Indeed, there are many functions that have been converted to macros
>by our header files.
This is often done because of efficiency (e.g. the <ctype.h> macros
will often be significantly faster if they are macros instead of
functions).
>1. This is correct:
>
>extern void *malloc();
If you include the <stdlib.h> header, it is not correct, at least
under ANSI C.
>2. This is correct:
>
>void *(*allocator)() = malloc;
Yup. The library should have a function called malloc even if it is
implemented as a macro as well. I think it does (at least my libc.a
contains malloc, and a quick test doesn't complain).
>3. This is correct:
>
>/* My-super-efficient-malloc: */
>static void *malloc(n)
>int n;
>{...
Nope, not if you include <stdlib.h>. You cannot have declarations /
definitions for malloc that specify both external and internal
linkage.
>In case you think these are far-fetched examples, and you don't think
>they are likely to bite us, I'd like to point out that both emacs 18.59
>and f2c _would_ compile out-of-the-box, but don't because of these errors.
I don't disagree with this at all. However, at least in this respect,
I think that emacs and f2c are broken, not our malloc. The best
solution, IMHO would be to fix them. Not that I particularly oppose
of removing any malloc macros, either.