Re: Run-time checking and speed

[dewar@cs.nyu.edu (Robert Dewar)]

>dewar@cs.nyu.edu (Robert Dewar) wrote:
>>
>> Mike, you miss the point that in some environments it is REQUIRED to turn
>> off runtime checking.
>>
>> Why, because runtime checking can create code that cannot be executed, and
>> in some verification environments coverage testing is required, so you cannot
>> have code and logic paths that cannot be executed.
>>
>
>Whenever we had such requirements, they were for the SOURCE code, not
>for the EXECUTABLE code! Are you telling me you actually dissasembled
>your executables and checked to make sure there was no dead code?
>Unless your compiler was REAL good at optimization, your executables
>were probably FULL of dead code by this definition.

Absolutely, I am talking about coverage testing on the generated object code,
which ensures that every reachable instruction has been executed by at least
one test program, and, in a stronger form, that every logic branch has been
executed both ways, and all branches of a case have been taken etc.

This seems normal to me in a safety critical environment (people aren't very
trusting of their compilers in such environments, or of anything else, and
that's the way you would hope it would be).

Dead code is a problem. You can take one of two approaches (I have seen both
done). First, you can just require that there be no dead code (code that has
no branch path to it should be trivially eliminated even by a pretty weak
optimizer, so I don't quite know what T.E.D is referring to when he says
that executables would be full of dead code. This is the approach that I
have most often seen used. The second approach concentrates on making sure
that all logic paths are tested, and then you don't care about dead code,
but I am afraid that in Ada you DO have to consider failing a check and
signalling an exception as a logic path, and making sure that all logic
paths are taken means making sure all exception handlers are executed.


Robert