4 ms·

Trying to avoid adding warnings is a very silly form to twisted logic. 1. People enabled warnings and -Werror because they want high quality code. 2. Standard

Trying to avoid adding warnings is a very silly form to twisted logic. 1. People enabled warnings and -Werror because they want high quality code. 2. Standard can't add warnings because people use -Werror This means that not adding warnings is directly against the original reason to use -Werror in the first place! We are now avoiding warning people about dangerous things because they requested to be warned about dangerous things!

flohofwoe 6y ago
The argument also doesn't make much sense because all 3 big compilers are already adding tons of warnings with each new release. Upgrading to a new compiler version and seeing screens full of warnings scroll by when compiling code that was warning-free in the previous compiler version is quite normal. Why does this affect the C committee's decision making, and why is it suddenly a problem?
- sramsay 6y ago
  If I'm following the author's argument correctly, the very influential companies who maintain very large, very old C code bases don't like what you just described -- new warning messages in code that used to not have any. They worry, then, that if the STANDARD actually mandates a warning, that is even more likely to happen, and that makes the very influential companies very sad. Which sounds like bullshit to me.
  - adrianN 6y ago
    It actually makes a little sense: Many companies are required to ship code without warnings (for example in safety-critical systems). Fixing warnings is very expensive and can introduce new bugs in code that has been running fine for decades. If you force new warnings into the compiler the result would be that these companies simply stop using newer versions of the compiler.
    - flohofwoe 6y ago
      Part of the normal "warning hygiene" process is deciding when a new warning in old code should be fixed and when it's better to suppress it. One my favourite warnings in this regard is gcc's misleading-indentation warning. The warning makes sense for new code written by a human, but if the code is machine generated, or decades old without showing any signs of problems caused by a "misleading indentation", then it is indeed much less risky to simply suppress that particular warning in that particular source file or library.
      - jschwartzi 6y ago
        The problem here is that if someone dies while using your medical device and you have a "warning hygeine" process then there's a sound legal argument that you knew there were problems in the device that you chose to instead paper over and ignore. It doesn't matter that it makes sense to software engineers. What you have to consider is how a "jury of your peers" will react to you calmly and rationally explaining that a newer version of the compiler added some new warnings, but you decided that because the code has been running just fine for decades that it's totally okay to not address those warnings. It raises questions about how seriously you're actually taking software quality. Take your "misleading indentation" warning. If you choose to ignore that warning, you're setting yourself up because I can make a great argument that you don't care that the indentation is misleading. And in fact that you're ignoring the hazards of following misleading indentation which is that another person reading your code could misread it and introduce a defect. And that in fact your policy is to allow some defects, including a possible defect which has killed the plaintiff.
        michaelt 6y ago
        Any organisation developing safety-critical code will already be following rules strict enough that they have an established deviation approval and documentation procedure. And frankly, the idea that people writing software where defects could kill people would prefer not to be shown new defects because fixing them is an inconvenience is a pretty insulting view of that industry's professionalism and ethics.
  - wglb 6y ago
    There was this marvelous Coverity article (that I can’t find now) that amplified on what you are saying. The title of the article was something like “There is no such thing as the C language”. Customers would demand support for their idiosyncratic code.

flohofwoe 6y ago

The argument also doesn't make much sense because all 3 big compilers are already adding tons of warnings with each new release. Upgrading to a new compiler version and seeing screens full of warnings scroll by when compiling code that was warning-free in the previous compiler version is quite normal. Why does this affect the C committee's decision making, and why is it suddenly a problem?

sramsay 6y ago
If I'm following the author's argument correctly, the very influential companies who maintain very large, very old C code bases don't like what you just described -- new warning messages in code that used to not have any. They worry, then, that if the STANDARD actually mandates a warning, that is even more likely to happen, and that makes the very influential companies very sad. Which sounds like bullshit to me.
- adrianN 6y ago
  It actually makes a little sense: Many companies are required to ship code without warnings (for example in safety-critical systems). Fixing warnings is very expensive and can introduce new bugs in code that has been running fine for decades. If you force new warnings into the compiler the result would be that these companies simply stop using newer versions of the compiler.
  - flohofwoe 6y ago
    Part of the normal "warning hygiene" process is deciding when a new warning in old code should be fixed and when it's better to suppress it. One my favourite warnings in this regard is gcc's misleading-indentation warning. The warning makes sense for new code written by a human, but if the code is machine generated, or decades old without showing any signs of problems caused by a "misleading indentation", then it is indeed much less risky to simply suppress that particular warning in that particular source file or library.
    - jschwartzi 6y ago
      The problem here is that if someone dies while using your medical device and you have a "warning hygeine" process then there's a sound legal argument that you knew there were problems in the device that you chose to instead paper over and ignore. It doesn't matter that it makes sense to software engineers. What you have to consider is how a "jury of your peers" will react to you calmly and rationally explaining that a newer version of the compiler added some new warnings, but you decided that because the code has been running just fine for decades that it's totally okay to not address those warnings. It raises questions about how seriously you're actually taking software quality. Take your "misleading indentation" warning. If you choose to ignore that warning, you're setting yourself up because I can make a great argument that you don't care that the indentation is misleading. And in fact that you're ignoring the hazards of following misleading indentation which is that another person reading your code could misread it and introduce a defect. And that in fact your policy is to allow some defects, including a possible defect which has killed the plaintiff.
      - michaelt 6y ago
        Any organisation developing safety-critical code will already be following rules strict enough that they have an established deviation approval and documentation procedure. And frankly, the idea that people writing software where defects could kill people would prefer not to be shown new defects because fixing them is an inconvenience is a pretty insulting view of that industry's professionalism and ethics.
- wglb 6y ago
  There was this marvelous Coverity article (that I can’t find now) that amplified on what you are saying. The title of the article was something like “There is no such thing as the C language”. Customers would demand support for their idiosyncratic code.