Eclipse CODAN (Static Code Analysis) for C/C++

The Eclipse CODAN (Code Analysis) plugin is part of CDT and is a powerful static analysis tool finding all kind of possible bugs and issues. Still to my surprise not many C/C++ developers take advantage of it maybe because they are not aware that it exists?

ups! Programming error catched by CODAN

ups! Programming error detected by CODAN

In this article I show a few tips how to effectively use it, especially with the NXP MCUXpresso SDK.

Outline

In this article I show how to use the CODAN feature in Eclipse using the NXP MCUXpresso IDE 11.2.1 and the NXP MCUXpresso SDK as example, but it applies to any other recent Eclipse distribution.

I show you how to use it and how to configure it. Because my mantra is to have warning free source code, I share my setting and tweaks how to reach this for example with the NXP MCUXpresso SDK.

For an actual example of CODAN finding a bug, see SDK I2C driver bug – NXP Community.

Usage

To run the static analysis, use the context menu on the project:

Run C C++ Code Analysis

Run C C++ Code Analysis

Running this might report a lot of errors and warnings because it might catch a lot of things which might be OK for your project. But you can configure the level of checking, either on a global (workspace) or local (project) level.

The global settings are under Window > Preferences > C/C++ > Code Analysis:

Workspace Code Analysis Settings

Workspace Code Analysis Settings

I recommend using project specific settings:

Code Analysis project settings

Code Analysis project settings

A confusing part is that the global settings seem to be OR’ed with the workspace ones? This is why I have the global settings with all items unchecked:

Unchecked global settings

Unchecked global settings

In the project settings I do have the following items disabled, because I do consider them as OK for my projects:

  • Coding Style
    • Line Comments
    • Multiple Variable declaration
    • Return with parenthesis
disabled checks

disabled checks

Suppress Issues

Issues are reported in ‘Problems’ view as well in the source editor view:

code analysis issue displayed in source editor view

code analysis issue displayed in source editor view

Clicking on the issue shows an explanation of the issue:

Code Analysis Issue Explanation

Code Analysis Issue Explanation

This adds a comment to the source requesting CODAN to ignore it:

Code Analysis Suppress

Code Analysis Suppress

Here is another example:

goto in SEGGER RTT

goto in SEGGER RTT

💡 Instead of using the ‘suppress’ menu I can simply write or paste that comment too.

MCUXpresso SDK

There are a few things to tweak the NXP MCUXpresso SDK to work with CODAN. First several of the header files provided by NXP lack the proper copyright information to be recognized by CODAN (see example above): these I do suppress as shown above.

Warnings for SDK

Warnings for SDK

Because CODAN analyses all source files in a project, this can cause issues if unused headers are present int he project. For example the NXP SDK includes in the CMSIS folder several header files which are for different compilers: they are not needed so I have them removed:

remove not used CMSIS files

remove not used CMSIS files

The other thing is that because RedLib (a custom library from NXP) does not fully follow the standard, CODAN reports several possible issues, including missing proper includes. I do recommend not using RedLib and using NewLib-nano instead:

Using NewLib-Nano

Using NewLib-Nano

The SDK startup code is not ‘clean’ as it has several forward extern declarations which are not used:

not used declarations

not used declarations

I usually fix them with deleting the not needed declaration in the source file.

Disable Files and Folders with Resource Filter

If you are using a source library and do not want to change it for CODAN, it is possible to disable files and folders for CODAN.

To disable analysis for a specific folder is different from excluding it for a build: Code Analysis works through the Eclipse Indexer, so I have to change the settings using the Resource Filter:

  1. Select the folder to be excluded
  2. Use the Properties context menu on that folder
  3. Go to Resource > Resource Filter and add a new filter
  4. Use the following settings:
    1. Exclude all
    2. Files and Folders
    3. Name matches *
Excluding for Indexer

Excluding for Indexer

If only some files shall be excluded: use a matching name filter.

This now excludes the files in that folder. Depending on your workspace Indexer settings, trigger an Index rebuild: context menu on the project and do an Index > Rebuild.

With this it should be possible a CODAN error and warning free build.

Summary

Static code analysis is very useful to catch possible bugs early in the development cycle. Eclipse CDT includes CODAN (Code Analysis) which does a good job. It might not be comparable to expensive commercial tools, but it is very worth to use it, especially because it is easy to use and free :-). If you want to use something else (free of charge) in addition to it, a look at CppCheck too.

Happy analyzing 🙂

Links

9 thoughts on “Eclipse CODAN (Static Code Analysis) for C/C++

  1. Hey Erich,

    Thank you for the introduction – I knew about the tool before (working generic C applications in Eclipse) but didn’t think to apply it to MCUXpresso IDE projects.

    I like these tools in theory, but they just don’t work out in practice; the biggest dealbreaker for me is given in your copy above; having to delete/modify library (or SDK) files to ensure error/warning free builds as doing this immediately starts making the code non-portable. Lesser issues are things like “line comments” (“//”) being flagged (I prefer them to traditional “/* … */” comments when on a single line) and “assignment in condition” (which I use a lot of but it doesn’t flag them in “for” statements) as well as “symbol is not resolved” (with FreeRTOS, I have a number of global task status variables that are defined in the .h file so they can accessed by other tasks directly without having to go through a queue request for the data). This means that I have to go through the lists and pick and choose which options I think are appropriate – which means that for new projects, the selections have to be updated/imported.

    The real value of a tool like this is looking for violations of coding rules written for a project/organization. I’ve always been taught that in a multi-developer project, the code should be written to a set of rules so nobody looking at a part of the code can figure out who wrote it. Unfortunately, most tools only check for somebody’s definition of “good coding” rules.

    I applaud your insistence on error/warning free builds – not enough developers understand the value of this basic but the critical piece of guidance for ensuring code will work as expected.

    On that last point, I should point out that the final arbiter of errors and warnings is the compiler – with modern systems, even the largest projects can be built in a few seconds (my 40k robot code builds in less than 5s) which means that checks are just a couple of mouse clicks away. But, I can see the value of something like CODAN for students and new C/C++ coders to flag things that they should be aware of and can consider whether or not it is a problem in the application and/or writing style.

    Have a Happy New Year!

    myke

    Liked by 1 person

    • Hi myke,
      to me it is always a combination of different tools making the job: compiler to be set to warn about nearly everything, using code reviews and using tools like CppCheck or CODAN and finally using dynamic analysis too.
      Some of the implemented checks by CODAN (like the C++ comments) are debatable: for a clean C code there should be no C++ comments, but libraries I use do not stick to that rule: so I’m fine to turn that rule off, but keep my own sources clean.
      It is always a balance between setting the rule checks and keeping the sources clean, same for keeping things uniform and the same across developers.
      To me the CODAN checks are rather simple but still useful: better to have them than not using any. It is always shocking to see that many still are not even using the simplest checks (see https://community.nxp.com/t5/MCUXpresso-SDK/SDK-I2C-driver-bug/m-p/1205035).

      Happy New Year too!
      Erich

      Liked by 1 person

  2. Pingback: Eclipse Indexer Debug Tips | MCU on Eclipse

What do you think?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.