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
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
https://lists.gnu.org/mailman/listinfo/autoconf
