5 ms·

The opinions of (future) compiler authors decides already wether your programm will work in all cases. With those warnings they indicate some of their decisions

The opinions of (future) compiler authors decides already wether your programm will work in all cases. With those warnings they indicate some of their decisions.

quotemstr 9y ago
Future compiler authors are at least in theory beholden to current language specifications. If a program does something legal that a compiler author feels is a bad idea, the compiler can whine all it wants, but it still has to compile the program. Compilers drop support for older specifications far less often than they add new warnings.
- AgentME 9y ago
  In general yes, but the posts above were talking about a warning about undefined behavior, so the standard says that anything could happen in that case.
- tomsmeding 9y ago
  This is especially true for warnings about && and || precedence. When you use those two operators in one expression without parentheses, IIRC both gcc and clang complain, but I once wanted to compile some software that thought it was a good idea to -Werror all the code and don't use parens around &&. Fun times fixing all the zillion makefiles that mentioned Werror. (Yay autoconf?)
  - pklausler 9y ago
    That's the one warning that I like to disable. I hate having to write superfluous parentheses around conjunctions. I mean, come on. It's just as lame as requiring them around multiplications would be.
    - mjevans 9y ago
      Even if /you/ know the order of operations, making them explicit with the parentheses provides clarity and allows future maintainers to quickly (and correctly) deduce the structure of the logical construct. I generally only leave them out in short simple to follow 'normal math' order of operations.
      - quotemstr 9y ago
        Sure. The rule you suggest might be good coding practice --- but people can disagree, and their omitting the extra braces doesn't make the code wrong. An existing correct program shouldn't one day stop building because someone added a warning that enforces your preferred operating precedence marking style.
        zaphar 9y ago
        That is because the compiler authors conflated warnings with a linter. Warnings should be used to indicate basically just two things. 1. Dead/Duplicated Code. 2. Probably Broken Code. Anything else is stylistic and the realm of opinion. Even if it's informed opinion enforcing it belongs in a linter.
        quotemstr 9y ago
        To be fair, a compiler contains all the infrastructure you'd want in a linter. I don't mind compilers having lint-like warnings: I just want them to very clear about the differences between these warnings and warnings that reflect functional problems with high probability.
        evincarofautumn 9y ago
        What I’d like is for compiler authors to just admit this and include a lint mode. There’s some practical and political difficulty with adding new warnings to a widely used compiler, partly because you don’t want to generate too many new warnings for existing code, partly because people compile with -Werror and upgrading the compiler will break (well, sprain) their build. Those difficulties would be easy to skirt by just tossing new warnings into lint mode and promoting them to compiler warnings if they turn out to be very useful in practice.
- bluGill 9y ago
  The C standard is dropping support for things like gets, a compliant modern compiler should fail to build any code that uses that. This is very controversial with compilers - and gets is among the most horrid thing that ever made it into a compiler.
  - quotemstr 9y ago
    PulseEvent and IsBadReadPtr are worse. Windows has some of the very best and the very worst in API design.

The opinions of (future) compiler authors decides already wether your programm will work in all cases. With those warnings they indicate some of their decisions.

quotemstr 9y ago

Future compiler authors are at least in theory beholden to current language specifications. If a program does something legal that a compiler author feels is a bad idea, the compiler can whine all it wants, but it still has to compile the program. Compilers drop support for older specifications far less often than they add new warnings.

AgentME 9y ago
In general yes, but the posts above were talking about a warning about undefined behavior, so the standard says that anything could happen in that case.
tomsmeding 9y ago
This is especially true for warnings about && and || precedence. When you use those two operators in one expression without parentheses, IIRC both gcc and clang complain, but I once wanted to compile some software that thought it was a good idea to -Werror all the code and don't use parens around &&. Fun times fixing all the zillion makefiles that mentioned Werror. (Yay autoconf?)
- pklausler 9y ago
  That's the one warning that I like to disable. I hate having to write superfluous parentheses around conjunctions. I mean, come on. It's just as lame as requiring them around multiplications would be.
  - mjevans 9y ago
    Even if /you/ know the order of operations, making them explicit with the parentheses provides clarity and allows future maintainers to quickly (and correctly) deduce the structure of the logical construct. I generally only leave them out in short simple to follow 'normal math' order of operations.
    - quotemstr 9y ago
      Sure. The rule you suggest might be good coding practice --- but people can disagree, and their omitting the extra braces doesn't make the code wrong. An existing correct program shouldn't one day stop building because someone added a warning that enforces your preferred operating precedence marking style.
      - zaphar 9y ago
        That is because the compiler authors conflated warnings with a linter. Warnings should be used to indicate basically just two things. 1. Dead/Duplicated Code. 2. Probably Broken Code. Anything else is stylistic and the realm of opinion. Even if it's informed opinion enforcing it belongs in a linter.
        quotemstr 9y ago
        To be fair, a compiler contains all the infrastructure you'd want in a linter. I don't mind compilers having lint-like warnings: I just want them to very clear about the differences between these warnings and warnings that reflect functional problems with high probability.
        evincarofautumn 9y ago
        What I’d like is for compiler authors to just admit this and include a lint mode. There’s some practical and political difficulty with adding new warnings to a widely used compiler, partly because you don’t want to generate too many new warnings for existing code, partly because people compile with -Werror and upgrading the compiler will break (well, sprain) their build. Those difficulties would be easy to skirt by just tossing new warnings into lint mode and promoting them to compiler warnings if they turn out to be very useful in practice.
bluGill 9y ago
The C standard is dropping support for things like gets, a compliant modern compiler should fail to build any code that uses that. This is very controversial with compilers - and gets is among the most horrid thing that ever made it into a compiler.
- quotemstr 9y ago
  PulseEvent and IsBadReadPtr are worse. Windows has some of the very best and the very worst in API design.