What level of static checks are you comfortable with? Because I don’t exactly think you’re wrong, but writing deviation reports for nearly every cast is a bummer, and I think many who have worked with high levels of static checks are familiar with the situation where there is no possible way to write a line of code that does not cause at least one message. I’ve spent days writing justifications for disabling particular messages (justifications such as “analysis tool authors misunderstood misra-c, here is evidence” or “reason for message is based on single paper from 1978, does not align with programming practice of the past 30 years”).
I’m net positive on static analysis, but I will forgive a lot of grumbling. It’s a lot of effort and does not catch many issues.
Furthermore, point 4 in the article (fixing unimportant warnings can cause bugs elsewhere) is real. I mean, it indicates issues with test coverage, but who doesn’t have issues with test coverage? Oh, 100% unit test coverage? Is that branch coverage or MC/DC coverage?
But anyway, on one team, when making warning fixes we would compare the final binary to show that with our compiler (the one that matters) our change produced identical output to the previous commit. If there actually was a bug that the warning found, well that was a whole different procedure.
I’m net positive on static analysis, but I will forgive a lot of grumbling. It’s a lot of effort and does not catch many issues.