Hacker News Reader

Comment by flohofwoe | Hacker News Reader

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.

View on HN

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.

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.

Warnings are not defects. You might be surprised how conservative (parts of?) that industry are.

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."

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.

> 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/...

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.

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).

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.

> 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.

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".

Reply on news.ycombinator.com