Ralf Wildenhues wrote:
> Well, it comes from the age-old interface of AC_FUNC_MALLOC (upon which
> lots of non-gnulib code relies, BTW).
>
> Are you suggesting that gnulib not use AC_FUNC_MALLOC, but use a copy of
> its own that does not #define malloc to rpl_malloc?
You're right, it's better not to do that.
In the long run, I would find it better if the autoconf macros listed
in section "Particular Function Checks" would hardcode only the test, not
the remedy. I.e. make the remedy action customizable, like for
AC_CHECK_FUNC. In the case of AC_FUNC_MALLOC the doc would change like this:
-- Macro: AC_FUNC_MALLOC([ACTION-IF-SUPPORTED], [ACTION-IF-UNSUPPORTED])
If the `malloc' function is compatible with the GNU C library
`malloc' (i.e., `malloc (0)' returns a valid pointer), execute
ACTION-IF-SUPPORTED. Otherwise execute ACTION-IF-UNSUPPORTED.
If ACTION-IF-SUPPORTED is not specified, it defines `HAVE_MALLOC' to 1.
If ACTION-IF-UNSUPPORTED is not specified, it defines `HAVE_MALLOC' to 0,
asks for an `AC_LIBOBJ' replacement for `malloc', and defines `malloc' to
`rpl_malloc' so that the native `malloc' is not used in the main
project.
However, one must think carefully about the meaning of
AC_REQUIRE([AC_FUNC_MALLOC]) if the macro takes arguments. Probably
an invocation of AC_FUNC_MALLOC with arguments should be ignored by
AC_REQUIRE([AC_FUNC_MALLOC]).
Bruno
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
