Best way to handle oddball header #includes for Cppcheck Report?
hoes.maarten at gmail.com
Sun Sep 30 13:16:16 UTC 2018
> I'm not sure how useful this is, overall. Apparently, Cppcheck is run
> on .cxx files without knowledge of the specific -I, -D, etc. compiler
> switches that our build system would pass to the compiler for a given
> .cxx file. That will always lead to issues (Cppcheck not finding an
> including, or even finding the wrong include if there is include files
> with identical names in different dirs?, or producing false positives
> because it mis-guesses about some -D macro setting) unless we restrict
> our build system to compile all files with the exact same set of
> compiler switches---something I don't see us moving towards.
Actually, these are all good points. I hadn't even considered these yet, I
went straight into 'oh-goody-shell-scripting-time!' mode. Sorry for that ;-)
Having said that, I personally do think it might reduce the noise of the
cppcheck report if cppcheck could at least be told :
1.) In what directories the include files are located (Yes, if you have both
foo/foo.h and bar/foo.h this will cause issues, but might still be
preferable to what we have now).
2.) What are some likely defines, like for example: -DLINUX (Duh),
-D__LITTLE_ENDIAN__/-D__x86_64__ (characteristics of the test system
cppcheck is currently run on) -D__GNUC__ (expected, and not likely to cause
issues if set for code that does not have GNU C extensions), and
-UMACOSX/-UFREEBSD/-U_WIN32 (script currently does not run on MAC, FreeBSD,
Just my 2$.
Sent from: http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
More information about the LibreOffice