Paul Eggert writes: > > I've been thinking lately about the issues surrounding this macro (see > > archives and TODO list). Is there any reason why AC_PROG_CC_STDC could > > not simply be folded into AC_PROG_CC? Is there any software that must > > avoid an ANSI C compiler at all cost?
> In the past I recall some problems with that macro, as it set options > that caused some compilers to become pedantic (e.g., to refuse to > define `fileno' in <stdio.h>, since the C standard does not allow > that). I can see that. The problem is that the macro tests the flags # AIX -qlanglvl=ansi # Ultrix and OSF/1 -std1 # HP-UX 10.20 and later -Ae # HP-UX older versions -Aa -D_HPUX_SOURCE # SVR4 -Xc -D__EXTENSIONS__ where -qlanglvl=ansi and -std1 select the "strict" ANSI mode, whereas one could use -qlanglvl=extended and -std to get the "relaxed" ANSI mode. However, both of these options are the default in newer compilers, so this code doesn't get exercised anymore. The only compiler I know of that needs a flag to grok ANSI code at all is HP-UX's. > A reasonable amount of GNU code still tries to be portable to K&R C. > GNU Emacs comes to mind. However, hardly anybody actually uses K&R C > compilers anymore, except perhaps the GCC folks while bootstrapping. > So the K&R mode doesn't get tested much these days. Code that tries to be portable to K&R uses some restricted subset of C that is portable both ways, so it wouldn't break if we ran it through an ANSI C compiler. There is, I claim, no code that we would have to be concerned about that, requires K&R semantics only. Such code wouldn't work with Autoconf anyway, because configure would pick up 'gcc' and that doesn't provide strict K&R semantics. If you're concerned about this, let's provide some sort of extra switch or argument to prevent AC_PROG_CC from setting ANSI C mode. But I think the default should be to provide a compiler setup that works for today's code. -- Peter Eisentraut [EMAIL PROTECTED]
