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>
