51–60 of 74 posts
Earlier quoted context omitted.
Better if the third parties hit you up with the bug report and you come back with a patch.
A warning doesn't stop them from filing a bug report. It doesn't have to be an error though.
> 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 bu…
"Now, some people (and I feel this group is growing) are going a step too far, by enabling -Werror __unconditionally__ in their software packages. And what applies to me - not being able to anticipate warnings in other compilers - of course applies to them as well"
"squid requires me to __doctor around in its configure__ script, and even __patch some Makefiles__, while qemu-linaro has a central location for it."
The complaint boils down to "-Werror is a development tool, so use it like that".
> 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 bu…
Why can't developers, y'know, ACTUALLY READ THE BLOODY WARNINGS? And then, y'know, they could FIX MORE THAN THE FIRST ONE after a single build pass?
In my observation, the problem is recompilation avoidance. If you miss it the first time around (maybe you're just trying to get the thing to run) they won't come back unless you do a full rebuild. With a little care you can build a build system that will print them out every time you run, but it takes some care.
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.
Summary: Enable -Werror in debug builds, disable it in production builds (in publicly released builds). Reason: -Werror is helpful for you, useless for a 3rd party.
It's not scalable for you either. If everything becomes an error, you can't go a single day without fixing it and everything the compiler + your dependencies - aka, just some other people you've never met - complains about. In particular if you update a library and they deprecate some functions, -Wdeprecated will start emitting some warnings, which are now errors. Do you think you can fix that in a day? It could take…
It doesn't take months to add -Wno-deprecated to a Makefile.
> 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 bu…
This all depends on how much your compiler changes and how often you upgrade the compiler. Do you fix all the new warnings before upgrading? If it's a large codebase, that can take a while. Meanwhile your continuous build can't use the new compiler. (Or in practice, that's when you stop using something like -Werror and start disabling the new warnings.) For most open source projects, it's probably not that big a deal…
Unless you're also monobuild (a nightmare at 100 MLOC no matter how you slice it, although I've heard enough horror stories that I bet such exists), you don't need to upgrade every project at the same time. And if you can't afford the dev time to fix that many warnings, you probably can't afford the QA time to verify the compiler upgrade didn't introduce any "new" bugs from e.g. previously benign undefined behavior that the optimizer can take advantage of now in new optimizations. Although this presupposes you've got decent control over pinning your compiler versions.
My experience has been that compiler upgrades generally don't introduce too many new warnings - I'll generally fix all the new warnings before switching over the CI servers, yes, although I've only dealt with compilers may introduce too many warnings to fix all at once, in which case I may temporarily squelch or downgrade the specific "lower priority" warning types (read: those that seem to be mostly false positives) and establish corresponding work items for going through the codebase to fix those individual warnings and unsquelching the warning type, as a means to unblock whatever high priority thing is requiring the new compiler in the first place.
...in other words, it may be sufficient in the short term to review the new types of warnings, which is mostly independent of codebase size, if only to create a backlog to prioritize and triage. And hey, maybe each new warning type is useless, in which case you've found a bunch of warnings to disable so they don't distract your fellow developers.
Earlier quoted context omitted.
It might be okay for your project, but there are many cases where warnings seriously get in the way (e.g., indirect throw/longjump but leaving out a return statement). Besides, the warnings depend on the compiler (which may be non-gcc/clang/vs) — and may not even make sense on a given system. So shipping with -Werror is not really a good idea. Put the important stuff in the tests.
> It might be okay for your project, but there are many cases where warnings seriously get in the way (e.g., indirect throw/longjump but leaving out a return statement). I'd prefer to explicitly annotate the indirectly throwing function as non-returning, when possible. Longjumps are rare enough for me I'd be willing to individually suppress them, or suppress them over a range of code where they happen to be common. I…
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.
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"
Earlier quoted context omitted.
It's not scalable for you either. If everything becomes an error, you can't go a single day without fixing it and everything the compiler + your dependencies - aka, just some other people you've never met - complains about. In particular if you update a library and they deprecate some functions, -Wdeprecated will start emitting some warnings, which are now errors. Do you think you can fix that in a day? It could take…
> In particular if you update a library and they deprecate some functions, -Wdeprecated will start emitting some warnings, which are now errors. Do you think you can fix that in a day? It could take months to fix something that's literally not a problem yet. It doesn't take months to add -Wno-deprecated to a Makefile.
After which you no longer have any visibility on what deprecated fxns you're calling, which means one day updating that library again is going to completely block you until you rework your interface.
-Wno-error=deprecated would probably be better.
Earlier quoted context omitted.
> It might be okay for your project, but there are many cases where warnings seriously get in the way (e.g., indirect throw/longjump but leaving out a return statement). I'd prefer to explicitly annotate the indirectly throwing function as non-returning, when possible. Longjumps are rare enough for me I'd be willing to individually suppress them, or suppress them over a range of code where they happen to be common. I…
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… 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 o…
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:
http://lists.llvm.org/pipermail/llvm-bugs/2015-February/0387...