Description of problem: cppcheck v1.86 on PCP source fails when it should pass. In fact, the previous version of cppcheck (1.85) does pass on the same source tree. The new version seems to ignore certain macros and/or fails to include headers correctly. Version-Release number of selected component (if applicable): cppcheck-1.86-1 How reproducible: easily Steps to Reproduce: 1. git clone https://github.com/performancecopilot/pcp.git 2. cd pcp; sudo dnf builddep build/rpm/fedora.spec 3. ./configure; make check Actual results: cppcheck fails on src/pmcd/src/config.c Expected results: cppcheck should pass, like it used to with v1.85 Additional info: See the travis-ci raw logs at https://travis-ci.org/performancecopilot/pcp And the following, as posted to the PCP upstream development list : mgoodwin@~/src/pcp/src/pmcd/src[master]$ make check cppcheck --std=posix --force --quiet --error-exitcode=1 pmcd.c config.c dofetch.c dopdus.c dostore.c client.c agent.c client.h pmcd.h [config.c:2430]: (error) syntax error make: *** [GNUmakefile:45: check] Error 1 there doesn't seem to be anything wrong with the PCP code : mgoodwin@~/src/pcp/src/pmcd/src[master]$ cat -n config.c | head -2431 | tail -21 2411 */ 2412 #if defined(HAVE_ST_MTIME_WITH_SPEC) 2413 if (pmDebugOptions.appl0) 2414 fprintf(stderr, "ParseRestartAgents: new configFileTime=%ld.%09ld sec\n", 2415 (long)statBuf.st_mtimespec.tv_sec, (long)statBuf.st_mtimespec.tv_nsec); 2416 if (statBuf.st_mtimespec.tv_sec == configFileTime.tv_sec && 2417 statBuf.st_mtimespec.tv_nsec == configFileTime.tv_nsec) 2418 #elif defined(HAVE_STAT_TIMESPEC_T) || defined(HAVE_STAT_TIMESTRUC) || defined(HAVE_STAT_TIMESPEC) 2419 if (pmDebugOptions.appl0) 2420 fprintf(stderr, "ParseRestartAgents: new configFileTime=%ld.%09ld sec\n", 2421 (long)statBuf.st_mtim.tv_sec, (long)statBuf.st_mtim.tv_nsec); 2422 if (statBuf.st_mtim.tv_sec == configFileTime.tv_sec && 2423 statBuf.st_mtim.tv_nsec == configFileTime.tv_nsec) 2424 #elif defined(HAVE_STAT_TIME_T) 2425 if (pmDebugOptions.appl0) 2426 fprintf(stderr, "ParseRestartAgents: new configFileTime=%ld sec\n", 2427 (long)configFileTime); 2428 if (statBuf.st_mtime == configFileTime) 2429 #else 2430 !bozo! 2431 #endif mgoodwin@~/src/pcp/src/pmcd/src[master]$ grep 'HAVE.*TIME' ../../include/pcp/config.h #define HAVE_CLOCK_GETTIME 1 #define HAVE_MKTIME 1 #define HAVE_STAT_TIMESPEC 1 /* #undef HAVE_STAT_TIMESPEC_T */ /* #undef HAVE_STAT_TIMESTRUC */ /* #undef HAVE_STAT_TIME_T */ #define HAVE_STRFTIME_z 1 #define HAVE_STRUCT_TIMESPEC 1 /* #undef HAVE_ST_MTIME_WITH_E */ /* #undef HAVE_ST_MTIME_WITH_SPEC */ #define HAVE_SYS_TIMES_H 1 The latest cppcheck on f28 (and f29) is cppcheck-1.86-1.fc28.x86_64. The issue doesn't occur with cppcheck-1.85-1. So this appears to be a bug in the new version of cppcheck. The changelog doesn't reveal much. Until that's fixed, our the PCP travis-ci checks will continue to fail. Manually running the 1.85 version (copied to /tmp/cppcheck) passes : mgoodwin@~/src/pcp/src/pmcd/src[master]$ /tmp/cppcheck --std=posix --force --quiet --error-exitcode=1 pmcd.c config.c dofetch.c dopdus.c dostore.c client.c agent.c client.h pmcd.h Manually running the 1.86 version fails: mgoodwin@~/src/pcp/src/pmcd/src[master]$ cppcheck --std=posix --force --quiet --error-exitcode=1 pmcd.c config.c dofetch.c dopdus.c dostore.c client.c agent.c client.h pmcd.h [config.c:2430]: (error) syntax error
Created attachment 1518312 [details] cppcheck log whith --quiet removed I don't think this is cppcheck bug and rather I think this is expected. You can see what is occuring here with removing "--quiet" option as attached. Now lots of macros appears in the output lines. As explained in "-D" or "-U" option of "$ man cppcheck", when cppcheck cannot find out header files and cannot determine if macros in the source file is defined or not, cppcheck tries to examine "all" the configurations (although Ι don't think cppcheck will check all the "combinations" of whether macros is defined or not) - when include directory is insufficient. Here cppcheck cannot find out config.h because include directory is not specified, so cppcheck cannot find out whether HAVE_STAT_TIMESPEC or so is defined or not, then it tries to check all (perhaps actually some) macros combination pattern. And actually when HAVE_ST_MTIME_WITH_SPEC, HAVE_STAT_TIMESPEC_T, .... are all undefined, the source actually causes error.
Hi, thanks for the quick response. I agree the include directories should be specified with -I. That way cppcheck would at least have a chance to find the macros. The syntax error ("bozo!") is deliberate when none of the expected HAVE_.*TIME.* macros are defined, which is kind of like an assert in the code. One point of the BZ was that this used to work with cppcheck v1.85, but now fails with v1.86. Regardless, src/pmcd/src/GNUMakefile knows the correct -I directories to specify (${CFLAGS} and/or ${LCFLAGS}), so I guess it should specify those directories for cppcheck in the "make check" target. I'll investigate adding those flags in the PCP src tomorrow .. and report back. Regards
Fixed upstream (and will be in pcp-4.3.1-1) by adding include paths to the cppcheck invocation. Mark Goodwin (1): build: add -I paths for cppcheck, fix travis-ci checking src/include/builddefs.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Details : commit c4388d3ee80bb14c96fe8eb46735abcfdc84606e (HEAD -> master, upstream-goodwinos/master) Author: Mark Goodwin <mgoodwin> Date: Sat Jan 5 08:43:17 2019 +1100 build: add -I paths for cppcheck, fix travis-ci checking RHBZ#1663372 - "pcp does not set include dir for cppcheck" Tweak the CPPCHECK definition in buildefs.in to specify some include paths, as recommended by the cppcheck maintainers in BZ1663372. modified: src/include/builddefs.in
pcp-4.3.1-1.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-05aa494895
pcp-4.3.1-1.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2019-2f1f39ec7a
pcp-4.3.1-1.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-2f1f39ec7a
pcp-4.3.1-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-05aa494895
pcp-4.3.1-2.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-dc1a78c8d2
pcp-4.3.1-2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2019-26d6a351e6
pcp-4.3.1-2.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-dc1a78c8d2
pcp-4.3.1-2.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-26d6a351e6
pcp-4.3.1-2.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.
pcp-4.3.1-2.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.