iWave Japan      Welcome to iWave Systems

Splint: A better Static Analyzer for Embedded Linux. Abstract

“Since human beings themselves are not fully debugged yet, there will be bugs in your code no matter what you do.”
-    Chris Mason, Zero-defects memo (quoted in Microsoft Secrets, Cusumano and Selby)

Most of the programmers usually think that the code is perfect, once it complied without returning any warning or errors. Are you one among them? Well, this assumption won’t help you always, especially when you play with C language. Since ‘C’ is an imperative (procedural) systems implementation language, it more closed to the system memory and low-level architecture. So, if doing something wrong with memory, which will directly affect the whole system in fact! Well, a static code analyzer like “Splint” can point out these defects especially in Embedded Linux.


n embedded system, almost all programs have to run “24x7” continuously! This makes sense about the efficient usage of the system memory. If a particular application unnecessarily taking considerable amount of memory, then this will probably cause for the “system crash”.
Linux is made up of ‘C’ so that when it comes to the Linux programming in embedded, an extra care should be required in memory consumption as well as coding efficiency. A typical compiler will only check the typo-syntactical errors but never check where the memory leak is occurring. Here comes the importance of specially designed tools for static code analysis.
“Splint (Secure Programming Lint)” is a tool for statically checking C programs for security vulnerabilities and programming mistakes. Splint becomes “handy” when it comes to the embedded world, especially dealing with Linux.
The advantage of splits includes but not limits to the following:

  1. Ability to interpret special ‘annotations’ to the source code, which gives it stronger checking than is possible just by looking at the source alone. Annotations are stylized comments that document assumptions about functions, variables, parameters and types.
  2. Splint is “cross- platform” tool so that it can use in both x86 and ARM architecture machines.
  3. Better customization to select what types of errors are reported using command line flags and stylized comments in the code.
  4. Full freedom to the user. Users can define new annotations and an associated check to extend Splint’s checking ability.
  5. Splint can check the infinite loop problem that couldn’t able to do by a run-time checker such as ‘valgrind’.
  6. Splint is free software released under the terms of the GNU (General Public License).

Ideally speaking, Splint can be use in almost all C programs and can find the bugs in user specific manner. The common (some of them can be find only with splint!) problems that can be fixed through the Splint are listed below.

  1. Using possibly undefined storage or returning storage that is not properly defined.
  2. Violations of information hiding.
  3. Dangerous aliasing.
  4. Problematic control flow such as likely infinite loops, fall through cases or incomplete switches, and suspicious statements.
  5. Dangerous macro implementations or invocations.
  6. Violations of customized naming conventions.
  7. Buffer overflows vulnerabilities.
  8. Modifications and global variable uses that are inconsistent with specified interfaces.
  9. Memory management errors including uses of dangling references and memory leaks.
  10. Dereferencing a possibly null pointer.
  11. Type mismatches, with greater precision and flexibility than provided by C compilers

How to start with Splint?

Well, the answer is very simple. The best way to learn to use Splint, of course, is to actually use it. The splint can be run by simply putting

Splint *.c

Where *.c means that you can list out more than one C file with splint. Splint alone normally show many warnings. So its up-to the user to taken care about all those, else one can suppress the warning by providing a suitable “flag”.

A typical example: The following code snippet just check the different characters which entered by the user. Though the initial ugly code is vulnerable, it not returns any error when it compiles!

Embedded Linux
 Figure 1: initial code snippet 

Splint can be run by splint file_name.c, where the ‘file_name’ contains the above code.

The splint’s output for the above code snippet shows below. 
                 Static Analyzer for Embedded Linux

Figure 2: splint’s output.

The splint’s warnings are highlighted in yellow colour for better understandability. Splint won’t fix the above vulnerabilities by default. User should take the decision and fixed it by applying the patches.

The below code snippet shows fixed source code. Please note that, this code is just for explaining the use of splint but not for the functional meaning. 

iWave Systems
Figure 1: fixed source code snippet.

Conclusion: Splint is a very powerful tool for static C code analysis. Since splint is cross platform, it can be efficiently use in embedded systems that mainly deal with ARM architecture .Though splint shows much kind of warnings and errors, it’s totally up-to the user to taken care and fixes it.

Learn the splint; play in embedded world, that too with free of cost!

Reference: Splint manual: http://www.splint.org/manual/

Ajith P V - Member Technical- Software
iWave Systems Technologies Pvt. Ltd.