Re: [Andrew Suffield <address@hidden>] Bug#157887: autoconf: various imperfectly formed functions in c.m4

[Paul Eggert]

> Date: Fri, 23 Aug 2002 14:31:56 +0100
> From: Andrew Suffield <address@hidden>

> > Autoconf doesn't assume that the system C compiler supports ANSI
> > prototypes.
> 
> Then it should test for that, not assume it is running K&R.

That is a bit too strong, as Autoconf-generated scripts work fine with
a Standard C compiler (either C89 or C99) as well as with K&R C.  Your
problem is that you are specifying a C compiler that rejects
traditional-style function definitions.  Such a compiler will work
perfectly well with many projects, but it is not a standard C compiler
and it will break Autoconf-generated "configure" scripts in several
cases.


> I find the "feature" of supporting K&R at the expense of ANSI to be
> rather less than useful, especially since almost all the
> autoconf-using project nowdays don't support K&R C anyway.

There are still some important exceptions, GCC itself being one of
them (for bootstrapping reasons), and Autoconf must support them.


> Additionally, if running with different CFLAGS is not supported,
> there's a different bug: autoconf uses whatever value for $CFLAGS you
> had set in the shell.

That behavior is documented in the Autoconf manual.


> I should be able to set CFLAGS to whatever I want to compile with,

Not if you set CFLAGS to a value that breaks the compiler.  The only
question here is what constitutes "breakage".

I'm sympathetic to your problem and I think Autoconf should be fixed
to allow overly-pedantic compilers like yours.  However, it's not a
trivial fix, since we must continue to support K&R C for some time.
The biggest problem will be things like AC_TRY_LINK_FUNC; I don't see
any easy way to fix that without changing the invoking syntax, and
that is not a backward-compatible change.