Which sounds like bullshit to me.
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.
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.
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.
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."
Aka. the no brown M&Ms (not the rapper!) policy
https://www.npr.org/sections/therecord/2012/02/14/146880432/...
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.
Say you've proved memory safety on your source. What you're compiling is no longer that source you have a proof about.
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.
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".
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.
-W2019q2
The acceptance criteria is controlled by the purchaser. The purchaser can and should audit for this attempt to slide in out of spec code.