Re: -Werror considered harmful

[Behdad Esfahbod <behdad behdad org>]

[Replying to all four messages below.]

On 13-02-26 03:19 AM, Dan Winship wrote:
> On 02/26/2013 02:39 AM, Behdad Esfahbod wrote:
> > In file included from ../../../glib/libcharset/localcharset.c:28:
> > /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/include/stdio.h:372:
> > error: no previous prototype for 'getc'
>
> This is a bug in whatever version of mingw you are using;
> -Wmissing-prototypes is not supposed to apply to system headers.

Interesting.  That didn't occur to me.  Thanks for the pointer.  Now I wonder
if there should be a mode to pkg-config or something to use -isystem for all
include directories, such that whatever package I'm compiling doesn't give me
warnings for any package I'm using.


On 13-02-26 04:07 AM, Tristan Van Berkom wrote:
> That being said, does glib not use the gnome-common macros,
> which include the --disable-fatal-warnings configure option ?

No.

> I've found this configure option to be helpful, not sure if glib still
> needs it to be added...

That helps.  But it's an annoyance.  I'm arguing that the problem should be
fixed at the source.

Lets look at it this way: there are a handful of glib developers, and
thousands of glib users.  It's clear to me that the burden of enabling errors
should belong to the developers, not the burden of disabling them to the users.


On 13-02-26 08:20 AM, Maciej Piechotka wrote:
> Wouldn't it be better to selectively enable the -Wall -Werror rather
> then selectively disabled it? People compiling the library potentially
> care less about warning/errors then developers and know less about build
> system (was it --disable-fatal-warnings? --disable-Werror? etc.)
>
> Enabling warnings is as hard as:
>
> CFLAGS="-Wall -Werror" ./configure .... && make

Exactly my point.  This is what I have in my .bash_profile:

# -Werror-implicit-function-declaration
# -Wbad-function-cast
# -Wno-cast-qual
# -Wmissing-include-dirs -Wswitch-default
# -Winline -Wstrict-aliasing
# -Wmissing-field-initializers
# -Wunreachable-code
# -Wfloat-equal
# -Wstrict-aliasing
# -Wshadow
# -Waggregate-return
#
GCCOPTS="-ggdb -O2 \
-Wall -Wextra  -Wno-missing-field-initializers \
-Wmissing-noreturn -Wundef -Wredundant-decls \
-Wsign-compare \
-Wlarger-than-65500 -Wpointer-arith -Wwrite-strings \
-Wformat=2 -Winit-self -Wswitch-enum -Wpacked \
-Wunsafe-loop-optimizations -Wmissing-format-attribute \
-fno-common -Wp,-D_FORTIFY_SOURCE=2 -Wno-strict-aliasing \
-Wcast-align -Wlogical-op \
-Wdisabled-optimization -Wvla \
-Wmissing-include-dirs \
"
export CC="gcc $GCCOPTS \
-Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes \
-Wold-style-definition -Wdeclaration-after-statement -Wnested-externs \
-Wlogical-op"
export CXX="g++ $GCCOPTS"
export CFLAGS="$CFLAGS -Wno-error -Wno-unused-parameter -Wfatal-errors"
export CPPFLAGS="$CPPFLAGS -Wno-error -Wfatal-errors -Wunused-macros"
export CXXFLAGS="$CXXFLAGS -Wno-error -Wno-unused-parameter -Wfatal-errors"


You see... I had to add -Wno-error to work around broken packages.  But that
doesn't work for -Werror=*.


On 13-02-26 11:48 AM, Colin Walters wrote:> Hi Behdad,
> At a high level, please keep in mind that you're working with a
> distributed group of people across the Internet who are actually trying
> to make the world a better place (for some loosely-aligned definition of
> "better").
>
> Adding the warnings turned up a large variety of bugs in GLib, and
> has been quite beneficial.

I'm not questioning that.  I think the right question would be: how many bugs
got fixed in GLib because of the warnings being enabled by default as reported
by people other than GLib developers (or those involved in enabling the
warnings)?  Also, I'm not even questioning the warnings.  I'm questioning the
errors.


> I'm sorry it broke for you, but please
> remember I'm not here to break things, so there's no need to start with
> the the "<rant>" approach.

Sorry about that.  I was just using the word in the Internet sense of it.


> And for reference, I did test building glib with mingw32 when landing
> the warning patch, and it still builds here (currently Fedora 18 x86_64
> with the packaged mingw32-* cross tools).

Interesting.  Because with my toolchain (Ubuntu 12.04.2 LTS) it was impossible
to build glib under mingw32 until I fixed it last night.


> That said, I think we can do something here to help people who have
> buggy toolchains, but don't care and just want some binaries.

Now I don't want to turn this into a distro flamewar.  Been there, done that.
 Fedora is great, but are you really saying that anyone on Ubuntu ought to
upgrade their mingw32 toolchain before compiling glib?  That doesn't make
sense to me.  Yes, I "don't care" as in, I'm not working on fixing glib
warnings right now, I just want a recent glib because I want to fix Pango
bugs.  Fixing glib warnings is the glib maintainer's job.  Fixing Pango bugs
is my job.


> I filed a patch here:
>
> https://bugzilla.gnome.org/show_bug.cgi?id=694757

Thanks.  Though I still believe that -Werror=* should be disabled by default.


-- 
behdad
http://behdad.org/