To generalize: Don't put debugging shit in production code.
Don't use -Werror
61–70 of 74 posts
Re: Don't use -Werror
#62Earlier 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…
> 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 */ };
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.
Re: Don't use -Werror
#63Earlier quoted context omitted.
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…
> 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…
> 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
Re: Don't use -Werror
#64Earlier quoted context omitted.
> 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…
> 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 compi…
> 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).
Re: Don't use -Werror
#65Earlier quoted context omitted.
> 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.
> 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.
Even better in my experience: A work item to be triaged, generated when you add either.
Re: Don't use -Werror
#66This article is basically a corollary of the Robustness Principal, "Be conservative in what you do, be liberal in what you accept from others". In this case we're accepting certain dependencies from others and we SHOULD be liberal/tolerant of dependencies that work but generate warnings.
Re: Don't use -Werror
#67There are some legitimate reasons for leaving -Werror enabled all the time. In the embedded world, for example, I'm less interested in supporting a wide variety of compilers, and more interested in rigidly complying with my particular toolchain's definition of "correct." In that case, I'm going to ask it to be as pedantic as possible because I'm never going to compile the code with any other toolchain, and I'd like to minimise the possibility of a bug because the code is going somewhere that a human won't be able to follow.
Re: Don't use -Werror
#68I see the issue as: there are warnings and warnings One thing is for the compiler to warn about something like implicit conversion of one type to another. Another, very different, if warning for things that are correct but might be in error (like 'for' without brackets, etc)
Non idiomatic code is an error. Not because computers have an issue, but because it wastes fractions of a second every time someone reads the code. PS: It's the same reason you capitalize the first letter in a sentence.
1 - That's the job of a linter
2 - automatically generated code has no obligation to be idiomatic
3 - If I had a cent for every time "idiomatic" code got in the way of readability I'd be a millionaire right now
Re: Don't use -Werror
#69Earlier quoted context omitted.
Non idiomatic code is an error. Not because computers have an issue, but because it wastes fractions of a second every time someone reads the code. PS: It's the same reason you capitalize the first letter in a sentence.
1 - That's the job of a linter 2 - automatically generated code has no obligation to be idiomatic 3 - If I had a cent for every time "idiomatic" code got in the way of readability I'd be a millionaire right now
If writing idiomatic code is causing readability problems your doing it wrong. Successful code is read far more than it's written and even machine generated code needs to be well written to locate bugs etc.
iF YoR CodE LoOks lIKe tHIs, yOu FaIl.
Re: Don't use -Werror
#70Earlier quoted context omitted.
1 - That's the job of a linter 2 - automatically generated code has no obligation to be idiomatic 3 - If I had a cent for every time "idiomatic" code got in the way of readability I'd be a millionaire right now
If writing idiomatic code is causing readability problems your doing it wrong. Successful code is read far more than it's written and even machine generated code needs to be well written to locate bugs etc. iF YoR CodE LoOks lIKe tHIs, yOu FaIl.
> If writing idiomatic code is causing readability problems your doing it wrong.
Sure, because breaking a 82 char line in python in 2 lines (because pep8) is much more readable than leaving it at 82 chars.