Whilst working on a recent project, I was visited by a customer QA representitive, who asked me a question that I hadn’t really considered before:
How do you know that the compiler you are using generates machine code that matches the c code’s functionality exactly and that the compiler is fully deterministic?
To this question I had absolutely no reply as I have always taken the compiler for granted. It takes in code and spews out machine code. How can I go about and test that the compiler isn’t actually adding functionality that I haven’t asked it for? or even more dangerously implementing code in a slightly different manner to that which I expect?
I am aware that this is perhapse not really an issue for everyone, and indeed the answer might just be… ‘you’re over a barrel and deal with it’. However, when working in an embedded environment, you trust your compiler implicitly. How can I prove to myself and QA that I am right in doing so?
For safety critical embedded application certifying agencies require to satisfy the ‘proven-in-use’ requirement for the compiler. There are typically certain requirements (kind of like ‘hours of operation’) that need to be met and proven by detailed documentation. However, most people either cannot or don’t want to meet these requirements because it can be very difficult especially on your first project with a new target/compiler.
One other approach is basically to NOT trust the compiler’s output at all. Any compiler and even language-dependent (Appendix G of the C-90 standard, anyone?) deficiencies need to be covered by a strict set of static analysis, unit- and coverage testing in addition to the later functional testing.
A standard like MISRA-C can help to restrict the input to the compiler to a ‘safe’ subset of the C language. Another approach is to restrict the input to a compiler to a subset of a language and test what the output for the entire subset is. If our application is only built of components from the subset it is assumed to be known what the output of the compiler will be. The usually goes by ‘qualification of the compiler’.
The goal of all of this is to be able to answer the QA representative’s question with ‘We don’t just rely on determinism of the compiler but this is the way we prove it…’.