Re: AC_PROG_CC_* shouldn't append multiple options

[Adrian Bunk]

On Fri, Sep 21, 2012 at 12:01:55PM +0300, Adrian Bunk wrote:
> 
> Marking AC_PROG_CC_C89/AC_PROG_CC_C99/AC_PROG_CC_STDC as obsolete
> (and turning them into aliases for AC_PROG_CC) is an option, and the 
> more I think about it, it seems like the only option where trying to 
> set the compiler into the highest possible mode in AC_PROG_CC makes sense.
> 
> Code today tends to be C89 with a few C99 features, so there is no 
> immediate benefit of C11 mode.
> 
> What exactly are the side effects of putting the compiler into the 
> highest possible mode?
> 
> Recent glibc hides the gets() prototype when the compiler is in C11 
> mode, which shouldn't be a huge issue.
> 
> Any other changes of C89/C99 behaviour that might affect code in 
> packages using autoconf?

Let me paraphrase the potential problem I have in mind:

As of autoconf 2.69, software using AC_PROG_CC and none of the 
AC_PROG_CC_* macros will be compiled in C89 mode. [1]

As of today, with autoconf 2.70 this software will be:
- compiled in C11 mode with gcc >= 4.7
- compiled in C99 mode with a variety of compilers on a variety
  of platforms

There are intentional changes caused by this (e.g. gets() no longer 
available in C11 mode), and the extend is unclear to me.

And there are also potential bugs that were never exposed before.
What if e.g. gcc 4.7 has some bug in C11 mode that would be triggered
by several packages?
It would be interesting to see the results of a distribution recompile
with "gcc -std=gnu11".

cu
Adrian

[1] ignoring the uncommon special case that a compiler might be in a 
    higher mode by default

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed