Linux_Exploit_Suggester VS Cppcheck

Linux Exploit Suggester - Heuristic reporting on potentially viable exploits for a given GNU/Linux system.

I dedicated Sunday morning to going over the documentation of the linters we use in the project. The goal was to understand all options and use them in the best way for our project. Seeing their manuals side by side was nice because even very similar things are solved differently. Cppcheck is the most configurable and best documented; JSON Lint lies at the other end.

Using infer, someone else exploited null-dereference checks to introduce simple affine types in C++. Cppcheck also checks for null-dereferences. Unfortunately, that approach means that borrow-counting references have a larger sizeof than non-borrow counting references, so optimizing the count away potentially changes the semantics of a program which introduces a whole new way of writing subtly wrong code.

Also check out (cppcheck)[https://github.com/danmar/cppcheck] if you want more static analysis

My browser refuses to open that link. This is better: https://github.com/danmar/cppcheck

cppcheck - Extensible C/C++ static analyzer focused on finding bugs.

and five C/C++ static code analyzers: * clang-tidy * oclint * cppcheck * cpplint (recently added!) * include-what-you-use (recently added!)

Start by feeding your codebase to a static analysis tool like cppcheck, to rule out obvious bound-checking mistakes in it.

Cppcheck is free. I've previously used it with a C++ project.