First of all (answering a question in the Autoconf TODO), yes, this macro needs to be renamed. There are to date three C "standards", only counting those by ISO/ANSI. And there are also several ways of interpreting what "standard C" refers to: 1) the compiler understands "standard" syntax, e.g., prototypes, const. 2) the header files declare all the standard symbols 2a) the header files don't declare any non-standard symbols 3) the library functions behave in a "standard" way Item 3 is covered by the rest of Autoconf, so let's look at 1 and 2. The Autoconf manual makes us believe that this macro essentially covers item 1 and that is does so by checking whether the compiler groks prototypes. Whether or not that is actually sufficient be a matter of another debate. But there are a number of things wrong in the implementation: 1) On some systems `cc' is a K&R compiler and the ANSI compiler is `c89'. In that case the configure script AC_PROG_CC AC_PROG_CC_STDC would first decide on `cc' as the compiler and then fail to switch it to ANSI mode, never considering `c89'. (The obvious solution would be to put `c89' before `cc' in the compiler search list, but that might have unwanted affects on programs that require a K&R compiler.) 2) The list of switches being considered is currently "" -qlanglvl=ansi -std1 -Ae "-Aa -D_HPUX_SOURCE" "-Xc -D__EXTENSIONS__" It would be very surprising if -D_HPUX_SOURCE and -D__EXTENSIONS__ actually had something to do with whether or not the system accepts prototypes. This looks more like objective 2 territory. (And in any case they should probably be AC_DEFINE'd.) 3) Many compilers seem to support a strict ANSI mode and a relaxed ANSI mode, for example `-std1' vs `-std', `-Aa' vs `-Ae', `-qlanglvl=ansi' vs `-qlanglvl=extended', `-pedanitic' vs `'. It's unpredictable which mode this macro will end up providing. 4) The interaction with AC_C_PROTOTYPES is somewhat non-obvious. I would have expected that PROG_CC_STDC would call C_PROTOTYPES to do the internal work, but as it turns out C_PROTOTYPES is really just a wrapper around PROG_CC_STDC. If you think about it, this would be equivalent to AC_C_CONST fiddling around with the compiler flags to get `const' working. In fact, you might get funny effects depending on whether you call C_CONST before or after C_PROTOTYPES. Macros from the `C' class should probably not call macros from the `PROG' class; more generally, public macros shouldn't call each other without the documentation mentioning it. As a solution it seems that the information about what kind of C compiler you want should be communicated already to AC_PROG_CC, perhaps as a second argument. Then it could check the flags in an inner loop for each compiler it finds. At the same time the macro AC_C_PROTOTYPES would be changed to a macro that does much of what AC_PROG_CC_STDC does now, namely check whether a prototype snippet compiles. In practice this would work like this: A) Need ANSI C compiler: AC_PROG_CC(, STDC89) B) Need K&R compiler: AC_PROG_CC(, K&R) C) Allow either: AC_PROG_CC ; AC_C_PROTOTYPES # to discover what you got In light of problem 3 above, however, the issue might be more compilicated because prototypes alone don't guarantee you anything about whether the compiler you found is good enough. Now about _HPUX_SOURCE and __EXTENSIONS__: I don't know what these do but there's definitely (non-trivial) software that happily compiles without them. It really seems like they're in the AC_AIX category and should be handled similarly. Depending on what they're good for they could perhaps be merged into AC_HEADER_STDC or into macros checking for specific function declarations. -- Peter Eisentraut Sernanders v�g 10:115 [EMAIL PROTECTED] 75262 Uppsala http://yi.org/peter-e/ Sweden
