The Elusive Search for a Pre-Qualified Standard Library

Let’s assume you are a software or safety manager, your C/C++ project is mission-critical or safety-critical, and your program development must adhere to strict levels of quality assurance – which might have to be verified by an independent assessor. If you are lucky, the requirements that must be met are laid down in a well-known standard, such as IEC 61508 or ISO 26262 (*).

Since you do not want to reinvent the wheel (see our previous blog: Standard or Third-Party Library – Which One to Trust), you want to use the existing standard library implementation that is supplied with the SDK (Software Development Kit) for your target hardware.

This is the challenge: how can you ensure the quality of that standard library implementation? Ideally, you would get that quality assurance from the supplier because you have your hands full managing the software that your own team writes. Unfortunately, that path is not so easy. In practice, very few libraries, if any, come with the guarantees that you need. There are some good reasons for that.

The library components that are going to be linked to your program have the same impact as your own code when things go wrong. For that reason, you take on some level of responsibility for the quality of the library implementation. You cannot just assume that the library that you use is OK, regardless of whether it is open source or from a vendor.

Safety standards do differentiate between third-party libraries and libraries that you maintain yourself. Your own libraries must meet the same requirements as any other application code. For third-party libraries, some of these requirements are waived, such as coding guidelines. It does not improve the quality of an established library to rewrite it for the sole purpose of meeting coding guidelines. But other requirements, such as verifying the library with a requirements-based test suite, must be met.

The context in which the library is used is the major reason why so-called pre-qualified libraries are not readily available. It is easy to assume that, because the standard library is provided in binary form, it is exactly the same implementation no matter the context of its use. That assumption is wrong. Parts of the library are supplied as source code in the form of header files. On a Linux system, take a look at the file /usr/include/stdio.h. It is a myriad of context-dependent #ifdef statements and additional #include statements. For C++, there is even more source code in the headers thanks to template code that must be instantiated when it is used.

As a result, significant parts of the library are compiled together with the rest of the application source code. The output is subject to the actual compilation options and other contextual settings, including macros set by the compiler itself, at that time. This is the so-called use case of the library. Qualification of the library must be performed for all possible use cases that are part of the application build process. The supplier of the library cannot possibly know these in advance and prepare for them because there are so many different combinations.

If you want to be sure that all your current and future use cases are covered, look beyond the vendor and evaluate SuperGuard, our requirements-based test suite for the C and C++ library that is built specifically for library qualification.

(*) For the purpose of this blog, I’ll use “quality” and “safety” interchangeably in the context of requirements, although they differ in important details.  Where safety is often an external requirement, quality is typically internally driven. However, their goals are well aligned, as are the methods by which they can be achieved. For that reason, if you are looking for quality, there is a lot to be gained by employing the tools used to achieve safety.