On Tue, Jun 3, 2014 at 10:54 PM, Stephan Neuhaus <stephan.neuhaus@tik.ee.ethz.ch> wrote:
... And that I think is going too far. There might be perfectly valid reasons to do what the developer did, and saying post-hoc that you fail the audit because you don't like some design choices opens the door to personal biases. (Good luck, for example, trying to write nontrivial C without at least some form of pointer arithmetic.)
there is a significant difference between engineering for safety, conservatively. and sloppy error prone techniques indicating haste and carelessness. pointer arithmetic in C may be unavoidable, yet using them consistently with thoughtfulness and robustness is always a great idea. defensive designs and conservative implementations are not "personal biases" in any form! [ what is defensive and conservative? well, i know it when i see it! *grin* ]
If you fail the audit, it's your duty as a professional auditor to provide evidence that there is something actually wrong with the software.
"why do I need to add braces around my if clause? that's your opinion about style, who cares??" 'you don't have to, but a trivial edit error could bleed you for years if you don't!' if (what) { goto fail; goto fail; /* fail safer! */ }