4 ms·

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 describ

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.
      - adrianN 6y ago
        Warnings are not defects. You might be surprised how conservative (parts of?) that industry are.
      - jschwartzi 6y ago
        And then I might ask you "so why did you apply for deviation on this warning? Warnings are bad, right? So shouldn't you fix a compiler warning if at all possible?" And then you might reply "Well no because this particular warning would require us to change some code that's really hard to change correctly so instead of spending the time and expense eliminating a potential defect we just left it in."
    - the8472 6y ago
      That hypothetical engineer would then argue with the counterfactual universe (our universe) where warnings were never added in the first place because people were afraid of adding warnings. I.e. punishing people for having this process sets the wrong incentives.
    - Konohamaru 6y ago
      > 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. Aka. the no brown M&Ms (not the rapper!) policy https://www.npr.org/sections/therecord/2012/02/14/146880432/the-truth-about-van-halen-and-those-brown-m-ms https://www.npr.org/sections/therecord/2012/02/14/146880432/...
    - wglb 6y ago
      There is a long distance traveled here between fine tuning warnings and medically critical software. The fact is that building such medically critical software (which I have done) has many more considerations than warning levels of c compilers. Additionally, there is the C language and what the standard says are two different things. Finally, the vast area of standard specified undefined and implementation defined areas substantially impact writing correct software.
  - guenthert 6y ago
    That misleading-indentation warning could also be suppressed by running the code through a beautifier before compilation (the pre-processor could be replaced so that this happens transparently on the fly).
    - fdupress 6y ago
      This also papers over a potential defect, but also introduces a potentially semantic-breaking process into your compilation pipe. Say you've proved memory safety on your source. What you're compiling is no longer that source you have a proof about.
      - guenthert 6y ago
        > This also papers over a potential defect That's what suppressing warnings tend to do, yes. > but also introduces a potentially semantic-breaking process into your compilation pipe. Only if the beautifier is broken. > What you're compiling is no longer that source you have a proof about. It sure is, again, unless the beautifier is broken.
        fdupress 6y ago
        So it turns out Materialistic doesn't even show responses to my comments unless I go back to the thread itself... The point I was making was in context of a discussion focused on mission-critical system. In that context, you can't just add a beautifier to your compilation pipeline with the argument that "the only way things will go wrong is if the beautifier is broken".
- sramsay 6y ago
  Yeah, and my snarky tone is probably not quite fair given that fact. Some of the "very influential companies" we're talking about are in aerospace, the automotive industry . . . the LoC numbers are truly immense, the standards compliance rules are incredibly strict, and everything moves slowly. I've never worked in an industry like that. A more charitable view of the situation would include some representative of an industry like that on the standards committee feeling their heart skip a beat because they realize that what is being suggested would cost millions to implement.
- wruza 6y ago
  Wait, wait, guys. Listen... -W2019q2 Cool, huh?
- erik_seaberg 6y ago
  “When a measure becomes a target, it ceases to be a good measure.”
- cbsks 6y ago
  If you are developing a safety-critical system you will not be upgrading your compiler without a very good reason to do so. In the safety-critical systems I've worked on, even the compiler options are set in stone. Changing either is a huge amount of paperwork and will probably require a re-certification of the entire system.
- pm24601 6y ago
  Not if the contract in question requires those issues being address. The acceptance criteria is controlled by the purchaser. The purchaser can and should audit for this attempt to slide in out of spec code.
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.

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.
    - adrianN 6y ago
      Warnings are not defects. You might be surprised how conservative (parts of?) that industry are.
    - jschwartzi 6y ago
      And then I might ask you "so why did you apply for deviation on this warning? Warnings are bad, right? So shouldn't you fix a compiler warning if at all possible?" And then you might reply "Well no because this particular warning would require us to change some code that's really hard to change correctly so instead of spending the time and expense eliminating a potential defect we just left it in."
  - the8472 6y ago
    That hypothetical engineer would then argue with the counterfactual universe (our universe) where warnings were never added in the first place because people were afraid of adding warnings. I.e. punishing people for having this process sets the wrong incentives.
  - Konohamaru 6y ago
    > 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. Aka. the no brown M&Ms (not the rapper!) policy https://www.npr.org/sections/therecord/2012/02/14/146880432/the-truth-about-van-halen-and-those-brown-m-ms https://www.npr.org/sections/therecord/2012/02/14/146880432/...
  - wglb 6y ago
    There is a long distance traveled here between fine tuning warnings and medically critical software. The fact is that building such medically critical software (which I have done) has many more considerations than warning levels of c compilers. Additionally, there is the C language and what the standard says are two different things. Finally, the vast area of standard specified undefined and implementation defined areas substantially impact writing correct software.
- guenthert 6y ago
  That misleading-indentation warning could also be suppressed by running the code through a beautifier before compilation (the pre-processor could be replaced so that this happens transparently on the fly).
  - fdupress 6y ago
    This also papers over a potential defect, but also introduces a potentially semantic-breaking process into your compilation pipe. Say you've proved memory safety on your source. What you're compiling is no longer that source you have a proof about.
    - guenthert 6y ago
      > This also papers over a potential defect That's what suppressing warnings tend to do, yes. > but also introduces a potentially semantic-breaking process into your compilation pipe. Only if the beautifier is broken. > What you're compiling is no longer that source you have a proof about. It sure is, again, unless the beautifier is broken.
      - fdupress 6y ago
        So it turns out Materialistic doesn't even show responses to my comments unless I go back to the thread itself... The point I was making was in context of a discussion focused on mission-critical system. In that context, you can't just add a beautifier to your compilation pipeline with the argument that "the only way things will go wrong is if the beautifier is broken".
sramsay 6y ago
Yeah, and my snarky tone is probably not quite fair given that fact. Some of the "very influential companies" we're talking about are in aerospace, the automotive industry . . . the LoC numbers are truly immense, the standards compliance rules are incredibly strict, and everything moves slowly. I've never worked in an industry like that. A more charitable view of the situation would include some representative of an industry like that on the standards committee feeling their heart skip a beat because they realize that what is being suggested would cost millions to implement.
wruza 6y ago
Wait, wait, guys. Listen... -W2019q2 Cool, huh?
erik_seaberg 6y ago
“When a measure becomes a target, it ceases to be a good measure.”
cbsks 6y ago
If you are developing a safety-critical system you will not be upgrading your compiler without a very good reason to do so. In the safety-critical systems I've worked on, even the compiler options are set in stone. Changing either is a huge amount of paperwork and will probably require a re-certification of the entire system.
pm24601 6y ago
Not if the contract in question requires those issues being address. The acceptance criteria is controlled by the purchaser. The purchaser can and should audit for this attempt to slide in out of spec code.

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.