[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AC_PROG_CC_C99
From: |
Paul Eggert |
Subject: |
Re: AC_PROG_CC_C99 |
Date: |
Sat, 01 Jan 2005 00:41:15 -0800 |
User-agent: |
Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) |
Roger Leigh <address@hidden> writes:
> Paul, the FSF have received the copyright assignment (Ted Teah said it
> would be processed after the new year).
Thanks!
> +** AC_PROG_CC_C89, AC_PROG_CC_C99
> + New macros for ISO C99 support. _AC_PROG_CC_STDC has been renamed
> + to AC_PROG_CC_C89. The shell variable ac_cv_prog_cc_stdc has been
> + renamed to ac_cv_prog_cc_c89 to reflect its more precise role.
A small point: NEWS should be written from the user's viewpoint, but
_AC_PROG_CC_STDC isn't user-visible. Can you please reword this
appropriately?
> -Paul Eggert notes that: ISO C 1999 says that @file{inttypes.h} includes
> address@hidden, so there's no need to include @file{stdint.h}
> +Paul Eggert notes that: @acronym{ISO} C 1999 says that @file{inttypes.h}
> +includes @file{stdint.h}, so there's no need to include @file{stdint.h}
"ISO" is not an acronym, so we shouldn't use @acronym for it. I
suppose we could use @sc instead, though after the next release of
Texinfo it might be better to use @abbr. ("ANSI" is an acronym so it
is right to use @acronym for it.)
> +If the C compiler is not in @acronym{ANSI} C89 (@acronym{ISO} C90) mode
> ...
> +If the C compiler is not in @acronym{ISO} C99 C mode by default, try to
C mode -> mode
> +if it handles _Bool, flexible arrays, inline, long long, mixed code and
> +declarations, named initialization of structs, restrict, varargs macros,
> +variable declarations in for loops and variable length arrays.
_Bool, inline, long long, restrict, and for should be in @code{...}.
> @@ -1246,7 +1435,7 @@
> AC_DEFUN([AC_C_PROTOTYPES],
> [AC_REQUIRE([AC_PROG_CC])dnl
> AC_MSG_CHECKING([for function prototypes])
> -if test "$ac_cv_prog_cc_stdc" != no; then
> +if test "$ac_cv_prog_cc_c89" != no; then
> AC_MSG_RESULT([yes])
> AC_DEFINE(PROTOTYPES, 1,
> [Define to 1 if the C compiler supports function prototypes.])
I don't see why this change is needed. It seems harmful, since it will
cause C99 compilers to appear to not support prototypes.
Also, I don't recall any response to my December 2 message
<http://lists.gnu.org/archive/html/autoconf/2004-12/msg00040.html>;
could you please take a look at the issues that it mentions too?
If you have time to prepare a revised patch, please CC: it to
address@hidden Otherwise, just let me know and I'd like to
install your patch as best I can. Thanks.
Thanks.
- Re: AC_PROG_CC_C99,
Paul Eggert <=