Verification and validation practices championed by functional safety, security and coding standards place considerable emphasis on showing how much of an application under test has been exercised. Experience has shown us that if code has been shown to perform correctly, then the probability of failure in the field is considerably lower. And yet almost without exception, the focus of this laudable endeavour is on the high level source code – whether that is written in C, C++, or whatever. Such an approach places a great deal of faith in the ability of the compiler to create object code that faithfully reproduces what the developers intended.
It is i nevitable that the control and data flow of object code will not be an exact mirror of the source code from which it was derived , and so proving that all source code paths can be exercised reliably does not prove the same thing of the object code. Worse, a nd despite their undeniable value, source code low-level test s (sometimes known as “unit tests”) can also be misleading because the object code derived from the compilation of a function wrapped in a test harness can differ markedly from that generated in the context of a complete system.
Uniquely amongst the functional safety standards across the sectors, DO-178C shines a spotlight on the potential for dangerous inconsistencies between developer intent and executable behaviour – and even then, it is not difficult to find advocates of workarounds with clear potential to leave th ose inconsistencies undetected. H owever such approaches are excused, th e fact remains that the differences between source and object code can have devastating consequences in ANY critical application. This paper explains why o bject code verification , or OCV ( Figure 1 ) , represents best practice for any system for which there are dire conseq uences associated with failure – and indeed, for any system where only best practice is good enough.
Figure 1: Applying object code verification with the LDRA tool suite
