The C Standard Library Cannot Be Trusted Blindly

Mon, 07/18/2022 - 17:57

In safety-related development, nothing can be trusted blindly. And the C Standard Library makes no exception. For a small selection, be aware that there are implementations in widespread use where:

  • sscanf() does things with errno it should not do;
  • iswxdigit() incorrectly recognizes some letters as hexadecimal digits;
  • mbtowc() reads memory it should not read.

Use of the C programming language for the development of safety-related systems is predicated on the following assumptions, where the third one has been largely neglected until very recently:

  1. Code has well-defined semantics and it is amenable to peer review
  2. The compilation toolchain has been suitably qualified
  3. The Standard Library has been suitably qualified

Let us briefly review these points in isolation and then see how they really work hand-in-hand toward the common objective.

 

1. Code has well-defined semantics and it is amenable to peer review

The C language has hundreds of undefined, unspecified and implementation-defined behaviors.  Any piece of code that is affected by those, either has no meaning at all (if it has undefined or critical unspecified behavior), or its meaning will be defined once all the details about the compilation toolchain are fixed —including all compiler command-line options— (implementation-defined behavior), or it will be non-deterministic even when all such details are fixed (unspecified behavior).  MISRA compliance is the best way to ensure that all such non-definite behaviors are properly taken into account.

In addition, unrestricted C, due to its inherent complexity, allows for the creation of code that is obscure to the point of making peer reviews and code inspections completely ineffective. MISRA compliance, by enforcing clarity in the use of language constructs, avoids this problem, which is not a secondary one: a well-defined semantics is a good thing in itself, but if team members are confused about what this semantics is, things cannot go well.

The certified ECLAIR Software Verification Platform® has been designed to ensure true MISRA compliance to a level of rigor that accommodates the requirements of the strictest functional-safety standards.

 

Learn about the ECLAIR FuSa Ecosystem

  See how ECLAIR works on eclairit.com   

 

2. The compilation toolchain has been suitably qualified

Let's say we have applied MISRA compliance in the proper way, i.e., as prescribed by MISRA Compliance:2020: the semantics of our code is well defined and the team fully understands it. What if the compiler miscompiles our code?  We would have struggled in vain. That is why functional-safety standards prescribe compiler qualification which, in practice, it is only achievable by running your compiler on tens of thousands of test-cases (all traceable to C Standard requirements) using the exact options you use in production in your environment.  This is what you can do with Solid Sands' SuperTest, either by yourself or via their excellent compiler qualification service.

Note that compiler qualification and MISRA compliance go hand-in-hand: see "Language Subsetting and Compiler Qualification" for more details.

 

3. The Standard Library has been suitably qualified

All C programs rely, more or less, on the C Standard Library. This reliance is recognized by MISRA: in fact, MISRA Compliance:2020 states that:

"As it is part of the implementation, and its functionality and interface are defined in The Standard, Standard Library code is not required to comply with MISRA Guidelines."

In other words, the Standard Library code is assumed to undergo qualification with the same rigor as the compiler. This is something that is too often overlooked: yes, the Standard Library comes with the compiler, but what is it? Is it a version of the GNU C Library, the BSD libc, dietlibc, Newlib, Bionic, musl, PDCLib, uClibc-ng, Dinkum C? It certainly has been adapted.  By whom?  Who maintains it? Has it been sufficiently tested as far as your functional-safety standard mandates?

Digging into the header files that come with your implementation can be instructive in this regard. Luckily, Solid Sands' new SuperGuard C Library Safety Qualification Suite finally addresses the problem in a fully satisfactory way, one that complies with the letter and spirit of functional-safety standards. SuperGuard provides tests and machinery allowing for thouroughly testing all C Standard Library  functionality against requirements and with full traceability information. Its availability actually closes a gap that has been present in the industry for too long: what functional-safety standards are (de facto) asking for is (a) MISRA compliance, (b) qualified compilers and static analyzers and, (c) qualified libraries, including the C Standard Library.

 

To conclude, let us show an example where these three aspects play together. According to the C Standard (e.g., C99:7.5p3),

"The value of errno is zero at program startup, but is never set to zero by any library function."

Very popular implementations of sscanf() violate the specification by zeroing errno when they shouldn't (you can see an example here). The mitigation for such misbehavior is already in MISRA C:2012: it is Rule 22.9,

"The value of errno shall be tested against zero after calling an errno-setting-function."

By following this rule, the clobbering of errno by sscanf() will be inconsequential, because the value of errno will have already been tested before the call to sscanf().

 

The importance of training in MISRA compliance

Proper training for developers and QA people is mandated by MISRA. Planning these activities on a regular basis is crucial to strengthen the confidence of your development team and improve the quality of the day-to-day work. BUGSENG trainings are held by qualified instructors, in collaboration with esteemed experts including members of the MISRA C, MISRA C++, and C standardization international working groups.

Check out the upcoming sessions:

12-16 September 2022 (held in Italian)
Registrations are open until 02/09
14-18 November 2022 (held in English)
Registrations are open until 04/11

 

26 July 2022 (held in Italian)
7 October 2022 (held in English)

 

Drop an email to training@bugseng.com to register and don't forget to join our LinkedIn community to keep up to date with all our news.

 

 
We are a passionate team of experts. Do not hesitate to let us have your feedback:
You may be surprised to discover just how much your suggestions matter to us.