Re: AC_PROG_CC_C99

[Paul Eggert]

"Kevin P. Fleming" <address@hidden> writes:

> Hmm... I see your point, but wouldn't that then mean that the macro
> would need to individually test for each C99 feature and store the
> results into variables for the configure script to check?

Yes, that's the basic idea.  Though there would be lots of macros, not
just one.  One for each feature that your project needs.  Many of
these macros exist already, e.g., AC_C_INLINE.

> Switching based on particular features they need sounds scary to me;

What can I say?  It's the Autoconf Way.  It works better in practice
than trying to switch on "C99" versus "C89", because real-world
compilers are rarely that simple.

> in a project where there are multiple developers who have been told
> "our project demands C99 support from the build system", they will
> feel free to use C99 features wherever they want.

Sure.  And such projects don't need to use AC_C_INLINE.  That will
simplify their Autoconfery and their codeing, at the expense of
preventing them from porting to pre-C99 hosts.  It's a tradeoff each
project can make on its own.

Personally, I don't advocate assuming C99 just yet -- only one C99
compiler exists right now, as far as I know, and it's not free -- but
other people might reasonably disagree and Autoconf can cater to them
too.  Also, people can assume some C99 features, if they like.  It's
up to them.

However, today I do advocate writing code that is portable to C99.
That is why it's OK to change AC_PROG_CC_STDC to prefer C99 to C89, if
both are available.  People's code shouldn't assume the features of
C89 that are incompatible with C99.

> the project could suddenly stop building on systems it used to build on
> because that compiler doesn't support all C99 features.

That's fine, for projects that want to assume C99.  Or perhaps I'm
misunderstanding your scenario?