Direkt zum Hauptbereich

Static analysis tool: cppcheck

This post shall be the start of a loose series on static code analysis tools that I've been using when professionally coding.
The tools should be compared against the same code base, so that one could get an impression what the benefits and flaws of a certain tool are.

Please put your questions/suggestions into the comments.

Today's tool should be cppcheck.

Supported Languages

  • C
  • C++
Dependencies (besides gcc)
  • libprce
Special features
  • custom rules for checking can be applied as prce-compatible regular expressions

Testing

  • Under test shall be the unmodified code of busybox version 1.29.2 as to be found as yocto-poky layer at gitrev 3541f019a505d18263fad0b46b88d470e3fd9d62.
  • As configuration for yocto the standard configuration is used.
  • cppcheck is used in version 1.87

Number of total findings in code: 308
Number of different finding types: 26

Findings in details class vs. count

nullPointer 3
memleakOnRealloc 2
nullPointerArithmeticRedundantCheck 2
shiftNegative 1
uninitvar 69
redundantAssignInSwitch 2
va_end_missing 2
invalidPrintfArgType_sint 35
invalidScanfArgType_int 22
signConversion 2
identicalConditionAfterEarlyExit 1
bufferAccessOutOfBounds 1
integerOverflow 2
uselessAssignmentPtrArg 1
invalidscanf 6
wrongPrintfScanfArgNum 1
shiftTooManyBitsSigned 13
leakNoVarFunctionCall 1
selfAssignment 71
constStatement 1
invalidPrintfArgType_uint 43
nullPointerRedundantCheck 3
resourceLeak 1
ignoredReturnValue 2
shiftTooManyBits 3
allocaCalled 18

Conclusion

Overall nive performance and quality of findings. Finds many common mistakes done when writing C-code.

Pros
  • Easy to build
  • Good quality of findings
  • Find the important stuff like shiftTooManyBits or integerOverflow
  • Extendible by custom rules
  • Relatively fast while executing 
Cons
  • Not many
  • Custom rules are hard to write (prce-regex in single-line mode (sic))
BTW if you want to use cppcheck out of the box in your YOCTO build see here
Labels:

Kommentare

Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

Sharing is caring... about task hashes

The YOCTO-project can do amazing things, but requires a very decent build machine, as by nature when you build everything from scratch it does require a lot of compilation. So the ultimate goal has to be to perform only the necessary steps in each run. Understanding task hashing The thing is that bitbake uses a task hashing to determine, which tasks (such as compilation, packaging, a.s.o.) are actually required to be performed. As tasks depend on each other, this information is also embedded into a hash, so the last task for a recipe is ultimately depending on the variable that are used for this specific task and every task before. You could visualize this by using a utility called bitbake-dumpsig , which produces output like this basewhitelist: {'SOURCE_DATE_EPOCH', 'FILESEXTRAPATHS', 'PRSERV_HOST', 'THISDIR', 'TMPDIR', 'WORKDIR', 'EXTERNAL_TOOLCHAIN', 'FILE', 'BB_TASKHASH', 'USER', 'BBSERVER&
Kommentar veröffentlichen
Mehr anzeigen

Making go not a no-go

Anyone that dealt with container engines came across go - a wonderful language, that was built to provide a right way of what C++ intended to do. The language itself is pretty straight forward and upstream poky support is given since ages... In the go world one would just run 1 2 go get github.com/foo/bar go build github.com/foo/bar and magically the go ecosystem would pull all the needed sources and build them into an executable. This is where the issues start... In the Openembedded world, one would have  one provider (aka recipe) for each dependency each recipe comes with a (remote) artifact (e.g. tarball, git repo, a.s.o.) which can be archived (so one can build the same software at a later point in time without any online connectivity) dedicated license information all this information is pretty useful when working is an environment (aka company) that has restrictions, such as reproducible builds license compliance security compliance (for instance no unpatched CVE) but when us
Kommentar veröffentlichen
Mehr anzeigen

Speedup python on embedded systems

Have you ever considered to use python as a scripting language in an embedded system? I've been using this on recent projects although it wasn't my first choice. If I had to choose a scripting language to be used in embedded I always had a strong preference for shell/bash or lua, because they are either builtin or designed to have a significant lower footprint compared to others. Nevertheless the choice was python3 (was out of my hands to decide). When putting together the first builds using YOCTO I realized that there are two sides to python. the starting phase, where the app is initializing the execution phase, where the app just processes new data In the 2nd phase python3 has good tradeoffs between maintainability of code vs. execution speed, so there is nothing to moan about. Startup is the worst But the 1st phase where the python3-interpreter is starting is really bad. So I did some research where is might be coming from. Just to give a comparison of
Kommentar veröffentlichen
Mehr anzeigen