15-01-2008, 08:00 AM
An example of code that can be reached but may never be executed: interrupt service routines written as defensive programming.
There is no way for a compiler (or static analysis tool) to predict which hardware interrupts that will occur in a system. Interrupts are not covered by the C standard nor explicitly by MISRA-C, yet there are few (if any) processors that lack interrupts. An interrupt must by definition be marked as reachable in some way, otherwise the code would be optimized to remove the interrupt, since it is never called by the code, but by the hardware.
In a safety-critical system, it is good defensive programming-practice to implement an interrupt service routine for every interrupt that is supported by the hardware, no matter if you will use that functionality or not. Because if the system is exposed to EMI, damaged external hardware, silicon bugs in the processor etc etc, it may very well execute those interrupts still. They should therefore be handled, so that the system may detect incorrect behavior and enter a fail-safe mode.
Such interrupt service routines are reachable, but will never be executed as long as the system works properly.
---
Though I think a lot of the confusion here comes from reading the document in English and not in \"Standardish\". In Standardish, the word \"shall\" is normative while \"may\" usually means \"may or may not\".
There is no way for a compiler (or static analysis tool) to predict which hardware interrupts that will occur in a system. Interrupts are not covered by the C standard nor explicitly by MISRA-C, yet there are few (if any) processors that lack interrupts. An interrupt must by definition be marked as reachable in some way, otherwise the code would be optimized to remove the interrupt, since it is never called by the code, but by the hardware.
In a safety-critical system, it is good defensive programming-practice to implement an interrupt service routine for every interrupt that is supported by the hardware, no matter if you will use that functionality or not. Because if the system is exposed to EMI, damaged external hardware, silicon bugs in the processor etc etc, it may very well execute those interrupts still. They should therefore be handled, so that the system may detect incorrect behavior and enter a fail-safe mode.
Such interrupt service routines are reachable, but will never be executed as long as the system works properly.
---
Though I think a lot of the confusion here comes from reading the document in English and not in \"Standardish\". In Standardish, the word \"shall\" is normative while \"may\" usually means \"may or may not\".