How to detect dead and unreachable code?
Axivion Suite detects code that does not get executed based on the following analyses:
By means of a reachability analysis on the call relation (i.e. the interprocedural control flow) of the analysed software, Axivion Suite finds dead functions. These functions will never be called and therefore will never be executed because there are no connections from the program entry points of the system (e.g. from main, interrupt handlers or callbacks) to these functions.
By means of deeper programme analyses, code areas within individual functions that are statically inaccessible and inaccessible in terms of programme logic can also be found (unreachable code, dead code, infeasible paths, unreachable statements, redundant catch blocks). These analyses are used by corresponding coding guidelines, for example by the MISRA rules. A simple example is code directly after a return statement. Another example is an else branch, which can never be traversed due to the variable values occurring in the conditions involved. Infinite loops can also be detected.
Don’t let dead code obscure your view
Code that will not be executed still needs attention. Dead code complicates comprehensibility, testability and maintainability. Special attention should therefore be paid to areas that “die” due to changes in code in the development process (does this happen intentionally and could these lines of code be removed completely?) or even never become alive (shouldn’t this code be alive at the end of a sprint or development cycle at the latest?). Here, the delta analysis of Axivion Suite comes into play. Through this direct feedback, preventive bug fixes and low-threshold refactorings can be guided precisely.
Are you building a library? Are you using interrupts?
A typical sticking point in dead code analysis concerns developers who develop libraries, frameworks or entire product families: In these cases the analysis can not be limited to a singe application. Rather, for a complete analysis, the entire set of applications has to be given to the analysis in an appropriate setup. Depending on the context of the question about dead code, the “living” parts can therefore be specified by means of various configuration options. For example, APIs can be marked as e to be considered “used” by the analysis.
By configuring the calling mechanisms of the operating system, the typical use cases can be simulated to take the interfaces into account accordingly during the analysis.
The configuration options are also useful for handling interrupt service routines and interrupt handlers.
Already at the level of the programme code (keyword interrupt, use of attributes), the corresponding functions for handling interrupts can be marked as alive.
You programme defensively?
The paradigm of defensive programming makes a lot of sense for the development of robust software, but often produces dead/unreachable code from the point of view of static analysis. Dead code as such is prohibited by the usual safety standards, as it often causes errors in the programming – nevertheless, these are code parts that you deliberately want to keep. Therefore, flexible configuration tools are available in Axivion Suite to “intentionally” mark dead code appropriately in the workflow and to take it into account accordingly in deviation management.
