On 2014-01-17 4:02 PM, David A. Wheeler wrote:
Zack Weinberg said:
For GCC I would be quite hesitant to turn anything on beyond -Wall
without explicit buy-in from the project, but I like the idea of
enabling -Wall by default.
I pretty sure that's what Dale Visser's patch does. It says: +
"-pedantic % -Wall" dnl GCC
Dale Visser's patch does include a comment that says: +# For the
GNU compiler it will be -Wall (and -ansi -pedantic) The result +#
is added to the shellvar being CFLAGS, CXXFLAGS, or FCFLAGS by
default.
But I think this comment is no longer true. It appears to me that the
code is just trying to see if "-pedantic" *WORKS*, and if it does,
then using that as evidence that "-Wall" would work.
Oh, is that what "-pedantic % -Wall" means? I had the impression it was
going to try each one in isolation and include the subset that worked.
Despite the dire things the GCC manual says about -pedantic, it is not
hard to write *new* code that is -pedantic clean, or -Wextra clean, etc;
I would support an opt-in mechanism for enabling a much more aggressive
set of warnings, and recommending its use in the manual for new
projects. But any such thing has a high probability of breaking *old*
code, hence my earlier comments. Also, as long as stock Autoconf checks
are sloppy (e.g. AC_CHECK_FUNCS and its habit of blindly declaring
everything as "char foo();") we will need to distinguish warnings
enabled for the *project* from warnings enabled for the *configure script*.
-ansi, however, should not be in there at all; it doesn't just turn on
strict conformance mode, it turns on strict *C89* conformance mode,
which is often wrong for new code. And even nowadays, strict
conformance mode in general tends to break system headers.
zw
