Re: [Libreoffice] cppcheck headers problem? (was 'Question about cppcheck "unused private"')

On 02/17/11 01:50, Caolán McNamara wrote:
> On Wed, 2011-02-16 at 20:09 -0800, someone@boldandbusted.com wrote:
> > Hi Caolán,
> >
> > So cppcheck can't find the headers it needs? Is this a bug in cppcheck,
> > or LO's construction of header file paths? And how many examples of
> > cppcheck false positives due to this problem are present? Does a clear
> > example of where cppcheck *should* find the headers but *doesn't* exist?
>
> So, in one sense there's an argument that if cppcheck can't find *all*
> the headers then it can't make any judgement as to the correctness of
> anything, e.g. the unfound headers might define all sort of stuff. e.g.
> there are headers in autodoc that define AND and OR and stuff like that.
> The whole language could be macro-ized to mean something totally
> different before it hits the compiler :-(
>
> See "Variable 'pProperties' is assigned a value that is never used" for
> an example where a macro is used that does use pProperties, and loads of
> the "class foo does not have a constructor" fall into this category I
> think.
>
> > Is there a way to prevent this particular problem for cppcheck?
>
> Strictly speaking, we have to pass equivalent -I args to cppcheck as we
> pass to the compiler to show it where all the headers are that the
> compile would include. In a super-strict sense this is complicated
> because some headers are generated at built time, and lots are
> "delivered", linked/moved into the solver/inc dir during the build to be
> included be later modules. Extra theoretical complications because some
> ifdefed headers and code only exist on some platforms, so the headers
> perhaps aren't available on the platform cppcheck is run on.
>
> So to be 100% perfect it needs to be run over a full build and with the
> same set of -I's as the compiler gets :-(, which would be awkward.
>
> On the other hand, we'd probably get 99% there if the cppcheck run was
> scripted to try and examine the makefile.mk in the current dir, take the
> "prj" path in there and add a few -I based off that path to the command
> line.
>
> e.g. take vcl/source/control/makefile.mk as an example, for the files in
> that dir the PRJ is ../.. and the PRJNAME is vcl, so 
> cppcheck -I. -I../../inc -I../../inc/vcl
> would find the majority of first-level includes and probably knock out
> most false positives.
>
> C.

Thank you for that detailed and very understandable explanation! :) I
will look into my options for extracting the Includes from makefiles
today. For me, I think the more difficult task will be keeping
cppcheck's included XML and HTML tools from clobbering their own
previous runs, and producing a unified output. I'd like to make
http://libreoffice.boldandbusted.com/ a better, more reliable reference
tool.

Cheers,

Jesse Adelman
Brisbane, CA
http://www.ilikelinux.com/
http://www.boldandbusted.com/