Re: Getting AC_PROG_CC_C99

[Bruno Haible]

Paul Eggert wrote:
> I don't think the autoconf patch would be that easy, as one would
> need to handle a mixture of AC_PROG_CC_C99, AC_PROG_CC_C89, and
> AC_PROG_CC_STDC calls.  Again, I expect the only thing that's
> saved us is that people just use AC_PROG_CC_STDC.  Hmm, maybe
> Autoconf should deprecate the other two macros?

There will soon be a new C standard, now codenamed C1X [1].

The description of AC_PROG_CC_STDC

 -- Macro: AC_PROG_CC_STDC
     If the C compiler cannot compile ISO Standard C (currently C99),
     ...

sounds like this macro will then be modified to enable C1X instead of C99.

But I expect that many packages will not need this. A package written to
use C99 will need AC_PROG_CC_C99, not AC_PROG_CC_STDC. 

The problems we have are:
  1) one cannot safely mix AC_PROG_CC_C99 and AC_PROG_CC_STDC [2],
  2) AC_PROG_CC_STDC will change its meaning in the future,
  3) AC_PROG_CC_C99 did not exist in Autoconf versions < 2.60.
  4) AC_PROG_CC_STDC does not enforce C99 mode in Autoconf versions < 2.60
     (says gnulib/modules/stdarg).

So, what people need to use now is
  m4_version_prereq([2.69], [AC_PROG_CC_C99], [AC_PROG_CC_STDC])

in the hope that Autoconf 2.69 will fix the first problem.

The sooner people can reliably use this idiom, the better.

Conclusion:
  - The fix of the first problem must occur in Autoconf before AC_PROG_CC_STDC
    gets changed to require C1X,
  - It makes no sense to deprecate AC_PROG_CC_C99.

Bruno

[1] http://en.wikipedia.org/wiki/C1X
[2] http://lists.gnu.org/archive/html/bug-gnulib/2011-09/msg00367.html
-- 
In memoriam Kelsang Namtso 
<http://en.wikipedia.org/wiki/Nangpa_La_shooting_incident>