And even if it were, it's a matter of adding -Wno-misleading-indentation to make builds green again. Not a big deal. And besides, it's likely that fixing those warnings could be done mechanically. (and it's hardly true that every project that ships with -Werror has such misleading indentation somewhere in its code)
Warnings are compiler version dependent (and even optimization level dependent, surprisingly). It looks like that one was introduced by gcc 4.6, so perhaps the author of the patch was using a different version.
Chrome builds with -Werror on by default but, because of the above reason, recommends any person attempting to build it to turn it off (and provides a flag to do as much).
> This flag adds a toolchain dependency to your project. Newer compiler versions (or alternative compiler vendors) are likely to generate new warnings, making the build fail.
IMO most large projects will anyway have multiple toolchain dependencies. Ever tried to compile Chrome using a different compiler/build system? And why would different contributors use different toolchains anyway? If you want to contribute, just use the same tools everyone else on the project uses.
When upgrading compilers, incompatible warnings are going to be the least of your worries. So what is the problem that the author wants to solve by not using -Werror? He agrees that warnings should not be merged. So why not stop them right when they're written?
> some compilers issue different warnings based on compile settings
Also based on which platform they're run on.
> new compiler versions regularly introduce new warnings,
Much worse, IMO is older compiler versions which emit incorrect warnings. At least when a new version emits a new, correct, warning it's at least something you want to fix (or disabling a new unhelpful warning). The failure to compile may still be a practical problem but at least the direction it creates is a right one.
For older compiler versions, there may be no fix-- breaking the code or turning off the warning may be the only options if Werror is used.
Outside of heavily controlled environments, however, Werror is just plain toxic. Want to run it on your CI builds where you don't need to worry about the compiler being upgraded or downgraded without warning? Great! Everyone should do that. Being warning clean on your primary target compiler(s) is an important move.
For code distributed to users the use of Werror use creates a pressure against introducing new and helpful warnings for compiler authors. Fortunately, it's such a nuisance for code distributed to others that no one survives enabling it for long and the worse damage it likely does is that the few projects that use it for publicly distributed code refrain from enabling many otherwise useful non-default warnings.
> -Werror is hardcoded in the configure script, which is a very bad idea, and the opposite of portable.
using -Werror is a guarantueed build break whenever the build is tried on a system the original developer had no access to.
I think that is exactly the point; if the thing does not build, people are going to complain loudly and things are going to get fixed. Warnings are usually just run-time problems waiting to happen, so they may as well be considered bugs.
>You won't even get a warning unless -Wextra or -Weverything is turned on.
I know people are used to languages where compiler warnings are on by default, but if you are building C without -W/-Wextra you are kind of asking for trouble. -Weverything is probably too pedantic for most people but -Wextra is pretty much required. And -Werror is required for projects where discipline can't be assumed or where the build log is bigger than a screenful.
Except that the comment I'm replying to says -Werror, meaning they would like to turn this warning into a build break. That seems a bit like language fascism to me. (And if it's not a build break, leaving the warning on stderr during a build is noise, which will cause you to ignore more important warnings.)
> Anyway, the best way is to enable as many warnings as you can, and have the discipline to fix the ones you see, without forcing yourself or anyone with -Werror.
Seeing as how easy it is to zap the -Werror from the configure script, I don't think that anyone is being forced to use it. However, making it the default helps avoid the opposite scenario where a growing amount of warnings (some potentially critical!) whizz past and nobody gives a shit.
So, the fact that warnings are enabled, they break built for some people, these people fix the issue and/or shout about it on the Internet (preferrably bugs@), it all is exactly what needs to happen. The problems get noticed and fixed this way. They don't just pile up. Yes it can be annoying, yes there are some stupid warnings -- ideally there'd be a flag -Wuseful-warnings. Yes people are free to zap the -Werror if they don't care about these warnings. Hopefully they know what they are doing because it really is possible that a bug in LibreSSL or in their system headers for example is calling for attention.
Consider how much discussion there was around goto fail and the like -- about the fact that static analysis (or smart compilers) would've caught these things. Why didn't they listen to the compiler?! So passing -Werror is one way towards making sure people look at the issues.
> There is a common complaint about my software - some compilers sometimes emit warnings when compiling some code, which some people sometimes find somewhat offensive. They can be very useful though, which is why I investigate the ones I know of.
If you don't take care of every warning you may miss a new warning amongst all the old warnings. That's why -Werror is nice, it forces you to deal with every warning as they pop up. Also when I compile someone else's software and there is a bunch of warnings popping up it makes me question the quality of the codebase. The code quality may be fine but it doesn't look good to the outside world.
> Even if you took care of all compiler warnings in all compilers for which you enable this switch, it's just a question of time till a new compiler version comes along that has a new warning message and - BOOM.
Great if a new warning pops up with a different compiler I want to know about that. It's either a bug in my code or a false positive. Using -Werror is more work but it improves code quality.
I've yet to be convinced that this makes sense for every warning. It really depends on the warning IMO.
Edit to elaborate:
I was mostly referring to non-committed/non-release code not deserving -Werror [1]. However, even for release builds, the story kind of depends on whether your builds are hermetic or not. If your commit also includes a snapshot of all your dependencies including your compiler toolchain executables, then off the top of my head, I can't think of any cases where you want warnings without errors (though perhaps there might be some). But if you're ever going to compile the same commit with a different toolchain (like say your system toolchain that you updated), then I don't think you want -Werror, otherwise every time the warning catches a new case, you'll fail to build something that previously compiled fine.
Quite a few of the warnings not enabled in -Wall or -Wextra fail spuriously on good code. In combination with -Werror, new failures on perfectly fine code is frustrating for developers.
> Enabling -Werror in distributions virtually guarantees that they won't build: Even if you took care of all compiler warnings in all compilers for which you enable this switch, it's just a question of time till a new compiler version comes along that has a new warning message and - BOOM.
This is a feature. This triggers a review of the new warnings introduced by the new compiler version, to see if they have found bugs, or should be squelched per false positive, or should be squelched project-wide.
> Two recent examples are squid and qemu-linaro, two packages I had to compile from source as Debian GNU/Linux didn't have (good enough, or any) packages for them.
The fundamental problem here is using a contributor's build environment (where I want -Werror to get them to contribute warning-induced bugfixes, or squelches/ignores if they're really false positives) for a non-contributor's task (where they just want the final binary, and aren't going to bother reporting the warnings even if I want them.)
Non-contributors building from source isn't a relevant niche to me (I generally ship binaries), but I can sympathize with the request for a warnings-as-warnings fast build path for them.
But make -Werror the default build path, for developers. This needs to be opt-out, not opt-in.
> Other people might be using different compilers that emit warnings for things yours didn't. You don't want the build to fail for those people.
Actually, you do. That way those things will be fixed and hopefully your inclusion of their fixes is a well motivated PR away.
Switching -Werror off should be a decision made with great care and understanding of what's going on under the hood. If there are platform specific issues then people on those platforms will be the ones in the best position to determine if such a warning is actually an error or not.
> The time you're spending reviewing warnings, determining warnings don't make sense, and individually suppressing warnings sounds like it could be considerable. Worse is that it's never ending - each new gcc/clang (or change from gcc to clang etc.) could bring hundreds of new errors…
Writing good code is time consuming. Remember warnings are potential bugs in your code, they should be investigated. Also if you start a project with -Werror you won't introduce lots of warnings at a single time.
> Otoh, gcc and clang now support colorized output. Warnings stand out a lot if you're building with make, and can be noted and disabled or fixed (if it's an actual problem) ${WHENEVER}, without having to drop everything now.
If you ignore warnings that are benign, over time there will be more and more warnings and it becomes harder and harder to notice new warnings that are bugs.
> I wonder if the argument for/against -Werror is really the difference between the beliefs "a compiler warning is probably a problem in my code" vs "a compiler warning is probably a problem in the compiler"
Compilers are remarkable pieces of software, in the last 4 years or so I can remember 3 compiler bugs I found in Clang and GCC and all were segfaults not incorrect warnings. That's after running Clang and GCC thousands of times on hundreds of projects. So as a rule of thumb if the compiler reports a warning it's correct.
Here's one of the compiler bug reports, I can't find the others:
>
Please, no, don't use -Werror with -Wall or -Wextra. When you write your code and compile with -Werror on your old version of GCC (either because you're behind on GCC releases, or because you wrote the code in the past), and I want to compile it with my new version which has added some warnings, I don't want to have to mess around in your build configuration and remove -Werror.
100% disagree. If compilers add new warnings it's because they have new insights in your code, and old invalid but "working" code may not work at all in the newer version and eat your hard disk. So instead of risking your data, just accept that it won't work with this newer version of the language.
> This new warning isn't enabled by default.
And even if it were, it's a matter of adding -Wno-misleading-indentation to make builds green again. Not a big deal. And besides, it's likely that fixing those warnings could be done mechanically. (and it's hardly true that every project that ships with -Werror has such misleading indentation somewhere in its code)
reply