CppCheck cleanup

[fallberg]

• Add support for inline cppcheck suppressions
• Clean out all known cppcheck issues
• Terminate toll-gate on found cppcheck issues

[fallberg]

I had to add this because the error is in a macro so it throws off the in-line suppression logic of cppcheck

[mfalkvidd]

Thanks for explaining why. Should the explanation be inline with the code instead of being in a comment in a review? Or would having inline comments clutter the code too much? We prefer having (doxygen)documentation inline, so maybe we should have cppcheck exceptions inline as well?

[fallberg]

I don't know if the cfg file supports comments. I have not been able to verify that.

[mfalkvidd]

Seems like it does. From the cppcheck manual:

Listing suppressions in a file

You can create a suppressions file. Example:

// suppress memleak and exceptNew errors in the file src/file1.cpp
memleak:src/file1.cpp
exceptNew:src/file1.cpp
// suppress all uninitvar errors in all files
uninitvar

Note that you may add empty lines and comments in the suppressions file.

[mfalkvidd]

Should we (manually, during code review I guess) encourage that the annotations are accompanied by a comment explaining why the suppression was added?

To take this code line as example, why do we want to suppress the warning?

If we decide to encourage commenting, should the comment be before or after the annotation? On the same line or above/below? /* style comment or // ? Consistency would make it easier for code contributors and reviewers.

[fallberg]

I can add further comments on the inline suppressions. Most of these are due to them being initialized in a init function, and to avoid claiming unnecessary memory because the class is instantiated but not used.

[fallberg]

In this case, I think it is a matter of the inputBuffer is used in a rats-nest of #ifdef:s which falls between the masks of the cppcheck grid (it will not evaluate ALL possible combinations of preprocessor flags).