A document type definition can help to work with corresponding files because it describes the involved data structures to some degree. Such a DTD can be added so that further improvements will become easier for the safe data exchange around library configurations for static source code analysis.

A DTD format was standardised as a basis for XML documents. Some technical challenges and limitations were noticed so that another standard like W3C XML Schema evolved. Such a XML schema definition can also be added so that corresponding file handling might become more consistent.

• Would you like to try this approach out?
• How are the chances to integrate this update suggestion into your source code repository?

First, each rule now has a "state" attribute:

Second, each rule has a list of IDs of rules to disable and a list of rules to enable if fired:

That's kind a weird style when derived class has a private method which is public in parent. You can't invoke it directly but could cast it to parent and invoke.

Hi guys,

We've been using cppcheck for our QT project but we kept getting false-positives from some of the functions that were exposed to QT so I've done a small patch that'll scan the code for Q_PROPERTY variables and also tokenize the QML (essentially javascript) sudo-code for calls that reference the C/C++ code.

//commit ---------------------------------------------------------------------------------------------

• Will check for Q_PROPERTY fields and remove them from the unused function list
• Will parse the .qml files (if they're in the source list of files to check) and remove references to C/C++ functions which would have otherwise been unused.

Use --enable=all or --enable=qt etc to enable the functionality and add the *.qml (i.e. src/assets) path to the command line interface invocation.

This is my third proposal for the building of the Cppcheck software with the tool "CMake" in this year. I hope that the chances will increase for integration of the suggested adjustments into your source repository.

Would you like to accept this retry?

I recognized several entries in the crash report which were outdated and when trying to run them locally it turned out the archive was no longer available. There's probably even more cases which might lead to the results not being updated, but there's currently no way to find this packages so I added a stale report which will show the results which are older than 30 days.

I also added the date and time to the crash report so it is easier to see which of the results are recent.

Linux distributions frequently lag behind actual releases. This offers users the opportunity to create their own packages easily.

Example usage:

$ mkdir build && cd build
$ cmake -DCPACK_GENERATOR=RPM ..
$ make package

Note that the version info is automatically computed from the output of git describe --tags.

Hi!

I would like to help to the project with this small contribution. I added a new way to configure, compile and install the project using CMake. I think that for people familiar with this tool, the configuration, build and installation of the project is more intuitive. I didn't touch none of the previous configurations, and all of them can live together.

Right now, I only tested that on Ubuntu 14.04 but It should be generic for any Linux distribution. If you decide to accept the contribution I can also deal with the Windows building (probably some minor changes should be made for that purpose).

I have also some other ideas easy to implement with CMake that could be interesting for the project.

When comparing same expression, this will follow variables if the variable hasn't been modified:

void f() { const int i = sizeof(int);  if ( i != sizeof (int)){}}

For integration with cmake and jenkins for a large-scale codebase, we'd like the XML results to be written to a specific file, rather than going to standard error.

A common mistake that I have found in our codebase is calling a function to get an integer or enum that represents the type such as:

int numBytes = numElements * sizeof(x.GetType());

This extends cppcheck for sizeof calculation to check for function calls as well.

I followed the documentation from https://libcxx.llvm.org/DesignDocs/DebugMode.html#using-the-debug-mode which refers to LIBCXX_ENABLE_DEBUG_MODE. But that is a CMake define you are supposed to pass when building libc++. Also the debug mode needs the library to be built with it which is not something we do. So as suggested we should enable the assertions via _LIBCPP_ENABLE_ASSERTIONS=1 instead - see https://libcxx.llvm.org/UsingLibcxx.html#assertions-mode.

When a .ctu-info file contains many macro definitions, the MISRA checks can take a long time (hours).

In our case, we are using libdivide which includes tens of thousands of machine generated macros.

The slow down is a result of the duplicate checks for MisraTypedefInfo, MisraTagNameand MisraMacro values, implemented as nested loops in analyse_ctu_info.

This PR replaces the nested loops with a temporary dictionary, keyed on the item name.

cli.vcxproj and testrunner.vcxproj are changed completely since the newlines were wrong (CR instead of CRLF). We need a proper .gitattributes file which enforces those. To view those changes you need to enable the Hide whitespace option in the diff viewer (accessible via the "gear" icon).

The added Label attribute is allowed - it is simply not used by Visual Studio in those files. It does allow use to define marker and the file lists in question so we can rewrite them.

I have no added writing of the *.vcxproj.filters yet but that is simply for grouping in the IDE and has no effect on the builds. Will add that in a later PR.

This has been on my TODO list for a while! I've been wanting to integrate CppCheck's results into GitHub since Code Scanning came out. To do that, however, the tool needs to spit out SARIF.

To test it out, run cppcheck --sarif --quiet foo.c

Now, this is only an initial stab, and it's probably a bit ugly. I'm not quite done just yet (hence why it's a draft PR). For one, it's not truly outputting the correct line/column numbers. So, if you have any suggestions or comments, please let me know.

Also, I initially tried to work SARIF output into the original design by adding a ErrorMessage::toSARIF method (ala ErrorMessage::toXML), but I quickly realized that this wouldn't work very well, since the SARIF document has to be "constructed", not "streamed" the way the XML document is. Which meant that I had to rework the way that findings ("errors") were collected and aggregated, since the SARIF document kinda needs to see everything all at once.