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   


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:

November 14-18 (20h, held in English) - Registrations are open until November 4
February 6-10 (20h, held in English) - Registrations are open until January 27


October 7 (6h, held in English) - Registrations are open until October 4
February 13 (6h, held in Italian) - Registrations are open until February 9


Drop an email to to register.


Webinar: A Rationale-Based Classification of MISRA C Guidelines

MISRA C is the most authoritative language subset for the C programming language that is a de facto standard in several industry sectors where safety and security are of paramount importance. While MISRA C is currently encoded in 175 guidelines (coding rules and directives), it does not coincide with them: proper adoption of MISRA C requires embracing its preventive approach (as opposed to the “bug finding” approach) and a documented development process where justifiable noncompliances are authorized and recorded as deviations. MISRA C guidelines are classified along several axes in the official MISRA documents. In this webinar, we add to these an orthogonal classification that associates guidelines with their main rationale. The advantages of this new classification are illustrated for different kinds of projects, including those not (yet) having MISRA compliance among their objectives.


Register to: "A Rationale-Based Classification of MISRA C Guidelines".

Wednesday, September 28th, 2022 - 11:00-12:00 CEST (UTC+2)


In our webinars, we cover the latest developments in MISRA C/C++ and BARR-C coding standards, static analysis tools, tool qualification, and compliance to industrial functional safety standards. Each webinar will last around 45-50 minutes plus 10-15 minutes for questions, and all are completely free.


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.