4 ms·

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 stat

by csl 10y ago

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.

Nullabillity 10y ago
> indirect throw/longjump but leaving out a return statement Hopefully a modern language would have a divergence type.
MaulingMonkey 10y ago
> 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've seen return warnings catch enough bugs that I believe this will save more time than it spends in the long run. If I didn't, I'd explicitly lower that individual warning's severity. I will also lower the warning's severity on a given compiler, if (but only if) I can't properly annotate it away on a given compiler. > Besides, the warnings depend on the compiler (which may be non-gcc/clang/vs) Again, feature. More coverage. Good. > and may not even make sense on a given system. In which case, upon reviewing said warning and determining said warning indeed does not make sense, said warning can be individually suppressed as mentioned. > Put the important stuff in the tests. This is a statically typed language. Successfully compiling is the first test. Successfully passing static analysis is the second test. Undefined behavior bugs can lead to some very subtle behavior that can be very difficult to unit test for, and tends to be quite sensitive to things like compiler flags, which call site they were inlined at, allocation patterns, etc. to even manifest in the first place. Given how nasty they can be to debug, they're also some of the bugs I'm most interested in catching - ideally before I commit, definitely before I ship. Taking full advantage of compiler diagnostics is way easier than e.g. writing enough unit tests to catch all UB caused from falling off the end of a non-void function without a return statement.
- powercf 10y ago
  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 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"
  - 2trill2spill 10y ago
    > 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: http://lists.llvm.org/pipermail/llvm-bugs/2015-February/038746.html http://lists.llvm.org/pipermail/llvm-bugs/2015-February/0387...
    - 10y ago

by csl 10y ago

Nullabillity 10y ago

> indirect throw/longjump but leaving out a return statement Hopefully a modern language would have a divergence type.

MaulingMonkey 10y ago

> 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've seen return warnings catch enough bugs that I believe this will save more time than it spends in the long run. If I didn't, I'd explicitly lower that individual warning's severity. I will also lower the warning's severity on a given compiler, if (but only if) I can't properly annotate it away on a given compiler. > Besides, the warnings depend on the compiler (which may be non-gcc/clang/vs) Again, feature. More coverage. Good. > and may not even make sense on a given system. In which case, upon reviewing said warning and determining said warning indeed does not make sense, said warning can be individually suppressed as mentioned. > Put the important stuff in the tests. This is a statically typed language. Successfully compiling is the first test. Successfully passing static analysis is the second test. Undefined behavior bugs can lead to some very subtle behavior that can be very difficult to unit test for, and tends to be quite sensitive to things like compiler flags, which call site they were inlined at, allocation patterns, etc. to even manifest in the first place. Given how nasty they can be to debug, they're also some of the bugs I'm most interested in catching - ideally before I commit, definitely before I ship. Taking full advantage of compiler diagnostics is way easier than e.g. writing enough unit tests to catch all UB caused from falling off the end of a non-void function without a return statement.

powercf 10y ago
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 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"
- 2trill2spill 10y ago
  > 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: http://lists.llvm.org/pipermail/llvm-bugs/2015-February/038746.html http://lists.llvm.org/pipermail/llvm-bugs/2015-February/0387...
  - 10y ago