Re: Selecting a C++ standard

[Adrian Bunk]

On Mon, Oct 29, 2012 at 10:50:10PM -0400, Trent Nelson wrote:
> On Sat, Oct 27, 2012 at 05:07:04PM -0700, Harlan Stenn wrote:
> > Adrian Bunk writes:
> > > On Sat, Oct 27, 2012 at 10:47:50PM +0100, Roger Leigh wrote:
> > > > Maybe have an optional argument to AC_PROG_CC_STDC to select
> > > > the standard e.g.
> > > >   AC_PROG_CC_STDC([C99])
> > > > ?
> > 
> > I like this idea.
> > 
> > > Latest discussion result was that there is no downside of setting the
> > > compiler to the highest mode possible.
> > 
> > Then that discussion was incomplete.
> > 
> > If I must ensure that a package requires a given "level" of STDC, then
> > configure MUST NOT decide any other "level" is OK.
> > 
> > > And as said above, feature testing is a separate issue.
> > 
> > that doesn't mean it is by definition OK to ignore this point.
> > 
> > > > I originally wrote AC_PROC_CC_C99 because it was several years
> > > > since GCC supported C99, but there was no portable way to use
> > > > C99 features with projects using autoconf unless you added
> > > > horrible hacks.  We still have this situation for C++, and it
> > > > would be nice to solve it in a similar way to C.  I'm happy to
> > > > go with the new approach of a single macro, but I would be
> > > > interested to understand how the issues I outlined above square
> > > > with this.
> > > 
> > > The main worry would actually be whether a compiler in C++11 mode might 
> > > reject any existing C++03 code.
> > 
> > I submit you are still ignoring the other side of the problem, which
> > says "Make sure I am using a C++03 compiler so I can be sure that the
> > package builds with a C++03 compiler if that is all *somebody else* has."
> 
>     I think this applies to us in the Python camp.  We use C89,
>     basically because that's the lowest common supported standard
>     across the board.  This is important to us for Windows and
>     MSVC support, as that will regularly balk on non-C89 code.
> 
>     So, in our case, we're not really in the position to use the
>     autoconf approach of test-for-the-feature-not-the-std-compliance;
>     we simply want to balk on non-C89 code on UNIX platforms, so it
>     can be fixed before it gets into the tree and breaks on Windows.


Python 2.7.3 and 3.3.0 have the following test for a C99 feature in 
configure.in:

  AC_MSG_CHECKING(for long long support)

If you would set the compiler into a mode where it balks on non-C89
code (-pedantic-errors with gcc), that test would always fail.

Large File Support (handling files > 2 GB on 32bit systems) is 
obviously also not possible when a compiler barks on non-C89 code.


Python 2.7.3 and 3.3.0 also have the following test in configure.in:

  AC_MSG_CHECKING(for _Bool support)
  have_c99_bool=no

Another test-for-the-feature-not-the-std-compliance for a C99 feature.


The first compile error I get with
  CC="gcc -pedantic-errors" ./configure && make
in Python 3.3.0 is:

Objects/bytearrayobject.c:2898:1: error: string length ‘513’ is greater than 
the length ‘509’ ISO C90 compilers are required to support 
[-Woverlength-strings]



>         Trent.

cu
Adrian

-- 

       "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