5 ms·

The time you're spending reviewing warnings, determining warnings don't make sense, and individually suppressing warnings sounds like it could be considerable.

• 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...
  • powercf 10y ago
    > 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 -Wno-XYZ the common ones that I don't feel are issues > > 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. What I mean is that, for example, gcc warning me about "if(x = y)" is a problem in gcc, as it's generating superfluous output for my correct, intended input
    • MaulingMonkey 10y ago
      > What I mean is that, for example, gcc warning me about "if(x = y)" is a problem in gcc, as it's generating superfluous output for my correct, intended input FWIW, it's now automatic for me to write if((x = y)) if that's actually what I meant. Or if (type x = y).
• MaulingMonkey 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. It can be. The thing is, I still spend more time debugging than writing code. The question is: Does this category of warning save me more time in bugs prevented that I don't need to debug, than it takes to review and suppress false positives? If not, I can disable the entire warning category. But otherwise - the considerable cost saves an even more considerable cost in debugging! Now, the time reviewing warning categories also takes some time, but it's been absolutely worth it in my experience. Even warnings which don't make sense to leave enabled globally can be useful - there are times when they make sense to force-enable locally. Clang can generate warnings about these two structures: struct foo { char c; /* 3 bytes implicit padding */ int i; }; struct bar { int i, j, k; /* possibly 4 bytes of implicit padding */ }; Totally worthless for 99% of my code. But if these structures need to be exactly the same memory layout between multiple compilers with different implicit padding rules - because they're memory mapped, or serialized as a simple char[] blob, or whatever else, it's a very useful warning to enable around the struct definitions! (I'll combine this with static asserts about structure sizes to seal the deal. No, just because they're the same size doesn't mean they were padded the same between compilers!) I've spent weeks tracking down issues that eventually turned out to be serialization mismatch related. Yes, it can be that subtle. I assume I saved at least a week between the multiple times I or a coworker triggered the warning-as-error modifying the structure. It took maybe a minute to look up the right warning, and to wrap the code in the relevant pragmas to force-enable it just for those structures. Worth! > 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" For me it's "I want to review every warning type, and decide how to handle it". Some of them are probably a problem in my code. These should remain errors - I need to fix them. Some of them are probably a false positive, but catch big issues that make it worthwhile anyways. These should remain errors - I can suppress them. Some of them are probably a false positive, and don't catch big issues, and just waste my time. These shouldn't even be warnings - I can disable them.