Andrew C Aitchison

It doesn't work like that. cppcheck works through both paths; if STDC is defined and if it is not. If cppcheck says there is no problem, your program will work whether the compiler has set STDC or not. *Since this could expand exponentially, by default only a limited number of configurations are tried. Use --force or --max-configs= to expand this limit.

https://github.com/cppcheck-opensource/cppcheck/pull/8648 - work in progress

I assume that you are using a Cppcheck build folder: option --cppcheck-build-dir=... This wont speed up analysis of individual files, but will avoid having to re-analyze files that have not changed. This option does not seem to be in man cppcheckbut is mentioned in cppcheck --help and in manual.pdf chapter 3.

I assume that you are using a Cppcheck build folder: option --cppcheck-build-dir=... This wont speed up analysis of individual files, but will avoid having to re-analyze files that have not changed. This option does not seem to be in man cppcheckbut is mentioned in cppcheck --help and in manual.pdf chapter 3.

https://cppcheck.sourceforge.io/manual.pdf chapter 17 (library-configuration) has some general advice about speeding up analysis. Another option, which would be a non-trivial amount of work and I am only guessing that this would ultimately be faster than cppcheck reading the header, is to write a custom .cfg library for this header. "You can use the Library Editor in the Cppcheck GUI to edit configuration files. It is available in the View menu." See manual.pdf chapter 14, and https://cppcheck.sourceforge.io/reference-cfg-format.pdf...

What happens if you have #define __int32 int ?

In that case it is definitely a bug in addons/threadsafety.py I note that cppcheck --enable=warning --addon=y2038.py test/main.c gives similar false positives. I copied this feature from y2038.py to threadsafety.py but I don't think my python is up to fixing this.

On Ubuntu 25-04 (Plucky) man ctime says (in the attributes table): Interface Attribute Value ctime() Thread safety MT-Unsafe race:tmbuf race:asctime env locale (see man 7 attributes for the detaiila of the terms used). so this is an edge case, but it is not obvious to me that it is a false-positive - what do others think ? Background The list of MT-unsafe functions in the threadsafety addon is computer-generated by tools/MT-Unsafe.py which reads the attributes table of man pages. We could ignore...