> Also, before upgrading the compilers on CI you need to fix any new warnings. But this isn’t a bad thing.
It's, in fact, downright stupid and means you're writing in a different programming language with each compiler upgrade and at the mercy of some poorly-considered third-party opinions.
Many compiler warnings are just stylistic. They can even contradict each other. Compiler A says, "suggest parentheses here". Oops, compiler B doesn't like it: "superfluous parentheses in line 42".
As a rule of thumb, warnings that aren't finding bugs aren't worth a damn.
The proper engineering approach is to evaluate newly available warnings and try them. Keep any that are uncovering real problems, or could prevent future ones; enable those and not any others.
Warnings are just tools. You pick the tools and control them, not the other way around.
Indeed. I just never really internalized all the operator precedence in C/C++ so I never write code like `a + b >> c`; I always add parenthesis when mixing arithmetic and bit operations.
Uhh, perhaps I'm not parsing your claim correctly, but that warning most certainly does exist in gcc.
$ gcc -Wall test.c
test.c: In function ‘main’:
test.c:6:5: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
if (a = b) {
^
Parentheses here would be superfluous, but would perhaps confirm you really intended to assign (i.e. used = instead of ==).
Putting parens around that example, while not strictly needed, also makes it harder to forget to add them if you later add an && or || to the conditional. So I am in favor.
It's, in fact, downright stupid and means you're writing in a different programming language with each compiler upgrade and at the mercy of some poorly-considered third-party opinions.
Many compiler warnings are just stylistic. They can even contradict each other. Compiler A says, "suggest parentheses here". Oops, compiler B doesn't like it: "superfluous parentheses in line 42".
As a rule of thumb, warnings that aren't finding bugs aren't worth a damn.
The proper engineering approach is to evaluate newly available warnings and try them. Keep any that are uncovering real problems, or could prevent future ones; enable those and not any others.
Warnings are just tools. You pick the tools and control them, not the other way around.
Every code change carries risk!