[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AC_CHECK_FUNC and C++
From: |
Paul Eggert |
Subject: |
Re: AC_CHECK_FUNC and C++ |
Date: |
Fri, 28 Sep 2001 09:56:09 -0700 (PDT) |
> From: Akim Demaille <address@hidden>
> Date: 27 Sep 2001 12:57:48 +0200
>
> More seriously, are you saying that we should move our model from
> `function present = can be linked' to `function present = is declared
> in the headers'?
I'm afraid I'm saying something even more drastic than that. I think
the model should be "function declared with the same compile-time
interface as expected". This means that the person who wants to check
the function has to supply a test for the desired interface. So
neither AC_CHECK_FUNC nor AC_CHECK_DECL will do as-is.
Here's one possible way out: leave the AC_CHECK_FUNC interface alone,
but add a new macro that specifies the desired interface. E.g.:
AC_CHECK_FUNC_API(strtol,
[[#include <stdlib.h>]],
[[
const char *str = "-2147483648";
char *endptr;
int base = 10;
long result = strtol (str, &endptr, base);
int strtol_size_ok[sizeof (strtol (str, &endptr, base)) == sizeof (long) ?
1 : -1];
exit (result != -1 - 2147483647);
]])
(The "exit" would be for use in other applications, which actually
want to test the function. I don't think it's needed for AC_CHECK_FUNC.)
If the above AC_CHECK_FUNC_API is in effect, then when the programmer
invokes AC_CHECK_FUNC(strtol), autoconf could check that the above
program compiles and links; otherwise HAVE_STRTOL would not be defined.
Autoconf could predefine AC_CHECK_FUNC_API calls for all the standard
functions, so configure.ac wouldn't need to use AC_CHECK_FUNC_API
unless it wanted to test a nonstandard function, or wanted to use a
different compile-time test.
Admittedly this is a big change. But something like this is needed.
The current AC_CHECK_FUNC and AC_CHECK_DECL stuff is hard to
understand, and makes code messy.
> Paul, there is something that seriously annoys me in Autoconf, and I
> asked for help several times, but never really totally understood the
> answers: why the heck do we have two means to check for the presence
> of a function?
In older implementations, functions often were not declared in any
header. I can't recall now, but I think some older POSIX versions
allowed this for functions returning 'int'. (POSIX 1003.200x won't
allow it for 'int' functions, but it's not official yet.) And some
really old implementations sometimes omitted declarations for
functions yielding types other than 'int'; the user program was
expected to declare them.
Hence, the original autoconf test was AC_CHECK_FUNC, since one
couldn't rely on the declaration existing.
Nowadays, this issue is becoming obsolete. Those really old
implementations are dead. It's been a while even since I ran
into an implementation that didn't declare 'int' functions.