And implying that there is 100% coverage just because the instruction register had all valid values is silly.
When writing test one should worry about the other registers too ...
When writing test one should worry about the other registers too ...
This concern has been nagging me in the back of my mind, but I hadn't convinced myself that code-coverage was insufficient (in practice) until you framed it this way.
Now all kinds of supporting examples come to mind:
- divide-by-0 errors
- floating-point exceptions
- numeric underflow / overflow (both silent and signaled)
The alternative code paths exercised by these situations are generally outside the purview of code-coverage tools, because they reside in the silicon / firmware, process' default signal handlers, etc.