Testing Out a Safe C Compiler

Being the Editor of Electronic Design has a few benefits and one is getting my hands on tools like IAR Systems’ Evaluation Kit for RISC-V. It contains a GD32VF103RBT6 RISC-V processor from GigaDevice Semiconductor. I did a hands-on review of that last year. This time around, I’m taking a closer look at the software side of things, including IAR’s MISRA C and its C-STAT static-analysis tools.

What is MISRA C and CWE?

MISRA is associated with the Motor Industry Software Reliability Association (MISRA). The Common Weakness Enumeration (CWE) is a “community-developed list of software and hardware weakness types” hosted on Mitre’s website. Both are designed to help create software that’s safe and reliable. MISRA, initially targeted at the automotive space, isn’t just for automotive applications, though.

In addition, there’s the CERT C/C++ Secure Coding Standard published by the Computer Emergency Response Team (CERT). The standard provides rules and recommendations for secure coding versus safety, which is the main concern for MISRA. As it turns out, error-free code is critical to both. In fact, major overlap exists between the various standards.

Like CERT, MISRA targets C and C++. CWE represent more generic recommendations that can be applied to most programming languages, although static-analysis support typically targets C, C++, and Java. Both include recommendations that can be implemented by static-analysis tools, while others require different methods to check or correct related problems. Those that can be checked via static-analysis tools are the focus here.

As one might guess, significant overlap also exists between MISRA, CERT, and CWE. These aren’t the only recommendations that can be addressed by static analysis tools. A number of companies offer static-analysis tools, such as LDRA, Grammatech, Green Hills Software, MathWorks, Parasoft, Perforce, Synopsys Coverity, and Veracode, to mention a few. There also are open-source solutions like Clang Static Analysis, cppcheck, and OCLint. The open-source tools aren’t quite up to the polish or functionality of the commercial products, but they’re very useful for those on a budget.

These tools are used extensively to support safety and security certifications like ISO 26262, IEC 61508, DO-178 and DO-254. They can flag problems ranging from catching null pointer problems to buffer overflows.

IAR MISRA C Support

As noted, most static-analysis tools available from vendors specializing in that area are independent of the C/C++ compiler. IAR’s C/C++ compiler is one of the few exceptions. Most will likely use IAR C-STAT (covered in the next section), which is on par with these solutions. C-STAT provides support for the latest MISRA standards in addition to addressing significantly more, including CWE recommendations.

Now for a couple of caveats. The MISRA C support isn’t enabled on most of the IAR eval kits at this point. The RISC-V kit is an exception in that it also includes C-STAT, which definitely makes it worth evaluating the software. The downside is that the functionality is only available for 30 days. I had to get an extension because I take forever to work on these hands-on articles. Fortunately, the extension was just long enough to finish up this article.

The MISRA support is easy to enable and the rules can be applied selectively (Fig. 1). From a developer standpoint, there’s really no difference between this and the C-STAT support, which is the same set of dialog boxes. In general, it’s a matter of enabling the desired rules so that the compiler will perform these checks.

Now for the fun part.

I don’t have a lot of RISC-V C apps these days. Most of my side work is in Ada/SPARK, Javascript, and PHP, so I decided to take crack at the runtime provided by IAR for the dev board. It turns out that these haven’t been run through the compiler with the checks turned on, but more than likely they did the same thing I did after getting a couple hundred warnings. This is typical of using static-analysis tools on legacy code.

On the plus side, disabling two rules cuts over 90% of the errors. One was Rule 5.1 that limits names to 31 characters. Of course, longer names can be useful in describing the functions; the runtime libraries take advantage of that aspect. Similar style-oriented rules as well as rules that deal with obsolete features common in legacy code can be disabled to trim the number of errors.

One can disable them for all cases, apply the rules selectively, or change the code. The first case is the most drastic and not a great idea. The second requires a bit of work and highlights the lines or files experiencing that issue. Hopefully it’s not all of the code. Changing code is the most drastic and requires the changes to be checked.

Once the code is adjusted, then developers making new changes can take the rules into account, allowing the compiler to do the checking. I’ve been using Ada lately and its rules are actually more limiting than what most C/C++ static-analysis tools require of programmers. I haven’t found Ada or MISRA to be a limitation once you get used to it. It’s on par with following company programming guidelines, but with the compiler doing the enforcement.

The compiler flags any errors including those related to MISRA, as usual. Links to the help system are available that explain the errors in detail, as are examples of good and bad code. This tends to make corrections easier or determine whether a particular rule needs to be disabled.

In general, a developer would not be enabling or disabling rules—this is typically done at a project level.

IAR C-STAT

C-STAT is IAR’s more advanced static-analysis tool (Fig. 2). It’s similar to competing solutions—all are separate programs that scan the source code for errors. They don’t generate object code like a compiler; they simply flag any errors.

Users of the Embedded Workbench will not really see any difference between using the compiler alone or adding C-STAT to the mix other than more detailed reports. C-STAT includes just under 700 rules, which can include those from MISRA C:2012, MISRA C++:2008, and MISRA C:2004, plus 250 IAR rules that map to CWE issues as well as compliance of CERT C coding standards. The tight integration with the Embedded Workbench means that C-STAT really appears to be part of the compile/link/debug cycle rather than a check/compile/link/debug cycle.

As it turned out, using the compiler support initially for the test code made the error list from running the code through C-STAT very short. Additional refinements and rules come into the mix as one moves to the latest versions of the standards. Addressing some of the security issues was something I didn’t delve into given the amount of time and due to the fact that this was legacy code. However, it was interesting to see what was flagged and what the solutions would be if coding changes were to be made.

Again, writing compliant code becomes significantly easier after doing it on a regular basis, and when checking is part of the development cycle used on a daily basis. This will not eliminate all bugs, but the tools can make a significant difference in the remaining amount of bugs.

Why Should Everyone Use Static Analysis?

I should have put this first, but if you got this far, you might be asking such a question. C and C++ have been used in embedded and system programming for decades. The problem is that even C++ is open to errors capable of trashing a system since there are few limitations on the programmer.

If you want to fill the stack with zeroes, then the system will merrily comply. Most programmers don’t want to do such things, but remembering all of the rules or finding all accidental errors is a challenge. The goal of error-free code is more easily attained when using tools that help rather than depending solely on a programmer’s eyes, concentration, and experience when dealing with tedious details.

It’s true the MISRA targets automotive applications and many of these tools, such as those from IAR, target safety or high-reliability applications. However, not using them for all C/C++ software is a waste, because they would improve the overall quality of software. They’re not silver bullets that will always catch all bugs. But by netting a significant number of them, static-analysis tools will benefit everyone by reducing the amount of time needed to debug problem code, or deploying code with few if any bugs.

The majority of program-related vulnerabilities would have been prevented by using most static-analysis tools. Many of the restrictions imposed by static-analysis rules are simply forcing good programming practices consistently.

Delivering safe and reliable code holds greater importance in the age of the Internet of Things. There are simply more components involved as well as more attack surfaces. Applications and middleware need to be equally correct at the operating system these days. Operating systems tend to be kept as small as possible so that they can be examined multiple times by eyeballs. Still, it’s useful for applications and middleware to get as much scrutiny even if its being done by software.

Artificial intelligence may start playing a part in the future, but for now, static-analysis tools like C-STAT can handle the majority of rules and checks. Like security, safety and reliability is something that needs to be addressed continuously. However, the major task of setting up the framework and rules to be used will be done rarely. Typically, a rule set will be selected and remain in use for years.

More developers are using static-analysis tools, but a significant number aren’t even aware of their value. Having worked for almost a decade with assembler, the move to C was fantastic in being able to developer cleaner, more reliable code. I’ve found the use of static-analysis tools and languages like Ada/SPARK to be a significant improvement as well.

It’s great if you’re already using static-analysis tools. If not, then definitely investigate the alternatives like C-STAT. They’re definitely worth it.