3 ms·

Most of our C code actually doesn't compile and work, unmodified, under the latest GCC. There are many new warnings, and like any professional C shop, we build

by geofft 6y ago

Most of our C code actually doesn't compile and work, unmodified, under the latest GCC. There are many new warnings, and like any professional C shop, we build with -Werror (or at least don't ignore the warnings). Since I help with maintaining the build infrastructure at work but I don't own any of the C code, I've proposed setting the new warnings to -Wno-error, but I've gotten pushback from the code owners, saying that they expect the new warnings to catch actual bugs and they want to deal with the fixes. Sure, there is some amount of C code from 25 years ago that works unchanged, but there's also a good bit of Python code from 25 years ago that works unchanged. (I just tried a few of the examples in the Python 1.3 tarball, released in 1995, and it seems like most of them will work with very minor changes.)

zajio1am 6y ago
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.

by geofft 6y ago

zajio1am 6y ago

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.