Best way to handle oddball header #includes for Cppcheck Report?

classic Classic list List threaded Threaded
4 messages Options
slacka slacka
Reply | Threaded
Open this post in threaded view
|

Best way to handle oddball header #includes for Cppcheck Report?

I am in the process of  teaching cppcheck about our source tree. So far I have reduced the number of warnings from ~9000 to ~100. In order for our weekly Cppcheck Report to benefit from these, I need to automate the process. Here is the command I used to list all of our include directories:

$ find . -type d \( -name "inc" -o -name "include" \) |sort > inc.txt

This cuts the warning from 9000 to 300, but there are some oddball #includes that this misses. Here is an example from 'vcl/qt5/Qt5Bitmap.cxx':

#include <Qt5Bitmap.hxx><--- Include file:  not found.

The complete path of this file is: ./vcl/inc/qt5/Qt5Bitmap.hxx
And my script already taught cppcheck about: ./vcl/inc

So I need to manually add: vcl/inc/qt5

So my question is how should this be remedied?

A) Change the include path to follow all 99% of the other include
like this:
#include <qt5/Qt5Bitmap.hxx>

B) Move the include file to an include folder

C) Or Keep a list of these oddballs and append them the results of my find command?

D) Write a smarter find command. Ideas?

Is there a guideline on include naming?  Many of these oddballs seem to be in folders that have been recently moved around the source tree. (vcl/inc/qt5 was just moved a few months ago)

So far, here is a list of the oddball include locations needed outside of those my find command located:

#include <Qt5Bitmap.hxx> :  vcl/inc/qt5
#include <charttest.hxx> : chart2/qa/extras
#include <gst/interfaces/xoverlay.h> : avmedia/source/gstreamer
#include <: I forget :(> : include/rtl

-Luke






_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
sberg sberg
Reply | Threaded
Open this post in threaded view
|

Re: Best way to handle oddball header #includes for Cppcheck Report?

On 12/09/2018 18:50, Luke Benes wrote:
> I am in the process of  teaching cppcheck about our source tree. So far I have reduced the number of warnings from ~9000 to ~100. In order for our weekly Cppcheck Report to benefit from these, I need to automate the process. Here is the command I used to list all of our include directories:
>
> $ find . -type d \( -name "inc" -o -name "include" \) |sort > inc.txt

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.

> This cuts the warning from 9000 to 300, but there are some oddball #includes that this misses. Here is an example from 'vcl/qt5/Qt5Bitmap.cxx':
>
> #include <Qt5Bitmap.hxx><--- Include file:  not found.

...which e.g. is because of

> $(eval $(call gb_Library_set_include,vclplug_qt5,\
>     $$(INCLUDE) \
>     -I$(SRCDIR)/vcl/inc \
>     -I$(SRCDIR)/vcl/inc/qt5 \
> ))

in vcl/Library_vclplug_qt5.mk.
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Maarten Hoes Maarten Hoes
Reply | Threaded
Open this post in threaded view
|

Re: Best way to handle oddball header #includes for Cppcheck Report?

Hi,


sberg wrote
> 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,
or Windows).

Just my 2$.


- Maarten.



--
Sent from: http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
sberg sberg
Reply | Threaded
Open this post in threaded view
|

Re: Best way to handle oddball header #includes for Cppcheck Report?

On 30/09/2018 15:16, Maarten Hoes wrote:

> sberg wrote
>> 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 :

I personally think a static analysis tooling with even only a single
false positive caused by inexact invocation of the tooling (i.e., not
passing the same command line switches as are passed to the real
compiler) would be just a waste of time (and I personally wouldn't even
bother looking at the results then).  Your mileage may vary---widely
even---of course.  And I surely don't want to kill any enthusiasm and
effort with this, just put it into perspective.

And from the other parts of this thread I see a move to that already
existing gbuild-to-ide thing, which sounds very promising.
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice