> -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.
C is not the same as other languages. Many possible errors reported by the compiler really are not bugs. You've probably heard of "-Wall" and "-Wextra". Why does -Wextra include even more warnings than -Wall? Because they're more likely to include truly spurious warnings. C is both more simple and more flexible than other languages, and it's very hard for the compiler to tell when the code does something the writer didn't intend.
As a trivial example, -Wunused will warn when a function has a parameter but doesn't use it. But you do this whenever you need to provide a callback that really doesn't care about one of the parameters. Still, -Wunused is helpful to find errors elsewhere in the code, so in these cases you might do something like
unused_param = unused_param;
just to make that one compiler warning go away. (That might work for one version of a compiler, but not another!) In other cases, the error the warning catches is so much more uncommon than the spurious warnings, you might disable that one warning type for your project. The linux kernel does this for a couple of them.
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. In any non-trivial codebase, you guarantee that the next major release of gcc will not be able to build your code if you use -Werror, due to some truly spurious warnings. Again, this isn't because gcc sucks, just because the problem of guessing where what you wanted is different from what you did is extremely difficult in C.
> 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.
While many of these warnings can be annoying during development they are also very useful if the code is kept clean of them. In this case the __bounded__ attribute is a security feature their compiler version has. If another platform can not support this feature then revoking this specific instance of this warning is an active decision someone should make when writing the build scripts. Just ignoring all warnings is certainly not the way to go.
The language often (always?) has facilities to remove those warnings on a case by case basis. For example when you don't want to use a parameter you can actively let the compiler know without assigning the variable to itself: you can only include the type and not the name:
int fn(int, void*);
int fn(int num, void* /*extra*/) {
// If the name extra is commented out the compiler will
// not warn that you are not using it. Now it is very
// clear that not using this variable was an active choice
// and not a mistake.
return num;
}
edit: as pbsd pointed out commenting out extra is not portable C code, though I believe the wider point still stands. These warnings can be very useful and should be be reviewed before ignoring them.
That's C++, not C. In C, the parameter name must be specified in a definition. I tried with 7 compilers, and none of them allow it as an extension, either, as they all consider it a fatal error.
In addition, correctness and security should always be prioritized ahead of portability. It does no good for software to be portable if that just means it's incorrect and insecure on more platforms.
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.