On 02/17/11 01:50, Caolán McNamara wrote: > On Wed, 2011-02-16 at 20:09 -0800, some...@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/ _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
