Only What You Use: Defining the Library Safety Envelope

Continuous Qualification means treating compiler and library qualification as an ongoing engineering process.

But what exactly needs qualifying in a library? Certainly not the entire library. We need to qualify a specific subset of it: the parts that are actually used by the application, under specific assumptions and configurations. Together, these define the library’s safety envelope.

In practice, this creates a challenge: the standard libraries of C and especially C++ are extensive; they contain thousands of functions and templates. Most applications only use a relatively small portion of this functionality, but what portion? This is not always obvious.

To remain within the safety envelope, the actual library usage must be identified accurately and consistently. With C, most of the library consists of functions and you can check which functions the linker needs to extract from the library. With the exception of some functions that have both a macro and a function implementation, this is quite robust.

But C++ is not like that. The C++ standard library contains large parts that are fully implemented in the header itself, especially for anything template-related. Nothing outside needs to be linked. In many cases, the code can be resolved completely by the compiler.

The use of templates, implicit operations and the presence of dependencies between headers mean that the effective scope of the used library components is not easy to see. As a result, developers may either underestimate the scope, risking gaps in qualification, or overestimate it, leading to unnecessary effort. Neither scenario is ideal.

CodeScout (developed by our partner BUGSENG) analyzes the application at build time to determine which parts of the library are actually used. It identifies the headers, declarations and dependencies, and produces a precise definition of the library subset that forms the qualification scope.

With the actually used subset of the library defined like this, it can be qualified by a comprehensive requirements-based test suite such as SuperGuard.

This approach keeps qualification complete and proportionate: only the code that is actually used is qualified, and it is qualified thoroughly. It reduces the risk of the safety envelope being too big (costly) and too small (dangerous) because computing the scope of the envelope is automated.

And with automation, library qualification can be turned into Continuous Library Qualification. As the application evolves, CodeScout can recompute the scope of the library required and compare it to the current envelope. If they are different, the user can choose to change the application or extend the scope of the library qualification. Most importantly, they remain fully in control and the qualification status is always up to date without manual analysis.

This transforms library qualification from a one-time, static activity into a controlled and repeatable process. Maintaining confidence in safety-critical software ultimately means staying inside the safety envelope, even as systems evolve. And that is no longer optional.