.webp)
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 single 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 so that they are considered “alive” 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. The corresponding functions for handling interrupts can already be marked as alive at the level of the programme code (keyword interrupt, use of attributes).
Do you code 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.
