3 ms·

If you compile with -Werror, then you are intentionally running it in no-backwards-compatibility mode. That is not really comparable with Python situation.

adrianN 6y ago
Actually GCC is very careful about adding new warnings to Wall because of backwards compatibility. That's a reason why Wall doesn't actually contain all warnings.
geofft 6y ago
Kind of, yes, but it's usually warning us about things that were actual bugs and reliance on unspecified/underspecified behavior that might be changing with newer optimizations.
- simias 6y ago
  Not really in my experience. I maintain some relatively old codebases and the most common warnings for old code with newer GCC generally are: - Warnings recommending the use of parens in code like `if (a || b && c)`. The original code is (probably) not broken, it's just that GCC thinks that it's error-prone to write conditionals that way (I agree). There's also a similar warning for code like `while (a = foo())` where it asks you to add parens to make sure that you didn't use = instead of == by mistake. - Warnings for unmarked fall-throughs in `switch`. Again, not broken if the fall-through was intentional. That's a fairly new warning, so a lot of all code will trigger it. - Warnings for some const to non-const pointer conversions (in particular for literal strings in C++). There you could argue that the original code is bogus but as long as the pointer is not written to it's fine. Const-correctness wasn't really a thing in C and C++ for a long time, a lot of legacy code plays fast and loose with const qualifiers, but that doesn't necessarily mean that the code is broken. - Warnings about unused variables, in particular variables being written to but not read. As compiler get smarter they tend to catch more of those.

3 ms·

If you compile with -Werror, then you are intentionally running it in no-backwards-compatibility mode. That is not really comparable with Python situation.

by zajio1am 6y ago

adrianN 6y ago
Actually GCC is very careful about adding new warnings to Wall because of backwards compatibility. That's a reason why Wall doesn't actually contain all warnings.
geofft 6y ago
Kind of, yes, but it's usually warning us about things that were actual bugs and reliance on unspecified/underspecified behavior that might be changing with newer optimizations.
- simias 6y ago
  Not really in my experience. I maintain some relatively old codebases and the most common warnings for old code with newer GCC generally are: - Warnings recommending the use of parens in code like `if (a || b && c)`. The original code is (probably) not broken, it's just that GCC thinks that it's error-prone to write conditionals that way (I agree). There's also a similar warning for code like `while (a = foo())` where it asks you to add parens to make sure that you didn't use = instead of == by mistake. - Warnings for unmarked fall-throughs in `switch`. Again, not broken if the fall-through was intentional. That's a fairly new warning, so a lot of all code will trigger it. - Warnings for some const to non-const pointer conversions (in particular for literal strings in C++). There you could argue that the original code is bogus but as long as the pointer is not written to it's fine. Const-correctness wasn't really a thing in C and C++ for a long time, a lot of legacy code plays fast and loose with const qualifiers, but that doesn't necessarily mean that the code is broken. - Warnings about unused variables, in particular variables being written to but not read. As compiler get smarter they tend to catch more of those.