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

[Caolán McNamara]

On Wed, 2011-02-16 at 20:09 -0800, someone at 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.