I just encountered an odd false positive on uninitvar. cppcheck is detecting an variable as uninitialized, although it has been set as the result of a getsockopt(). Specifically, with the attached example file:
$cppcheck--enable=all --library=posix --suppress=missingIncludeSystem --suppress=unusedStructMember --suppress=unusedFunction --include=/usr/include/linux/tcp.h cppcheck-getsockopt-uninitvar.cCheckingcppcheck-getsockopt-uninitvar.c...Checkingcppcheck-getsockopt-uninitvar.c:__BIG_ENDIAN_BITFIELD...cppcheck-getsockopt-uninitvar.c:21:2:warning:Assignmentoffunctionparameterhasnoeffectoutsidethefunction.Didyouforgetdereferencingit?[uselessAssignmentPtrArg]tinfo=&tinfo_new;^cppcheck-getsockopt-uninitvar.c:19:24:warning:Uninitializedvariable:tinfo->tcpi_retransmits[uninitvar]printf("%u\n",tinfo->tcpi_retransmits);^cppcheck-getsockopt-uninitvar.c:13:6:note:Assumingconditionisfalseif(!tinfo){^cppcheck-getsockopt-uninitvar.c:19:24:note:Uninitializedvariable:tinfo->tcpi_retransmitsprintf("%u\n",tinfo->tcpi_retransmits);^Checkingcppcheck-getsockopt-uninitvar.c:__LITTLE_ENDIAN_BITFIELD...nofile:0:0:information:Unmatchedsuppression:unusedStructMember[unmatchedSuppression]nofile:0:0:information:Activecheckers:110/966(use--checkers-report=<filename> to see details) [checkersReport]
The FP appears to be quite sensitive to the particulars:
* Removing the final pointless assignment of tinfo (correctly warned by cppcheck) removes the uninitvar warning
* Setting tinfo = NULL rather than passing as a parameter removes the warning
It does not. It does appear if I replace the --include with -I /usr/include so cppcheck can find the header that way. That also triggers a bunch of other warnings from headers, though.
The warning also appears if I don't include that header, but locally define struct tcp_info. The bug originally appeared that way, but it's a large structure, so I used the header for brevity,
The warning does not appear if I use the version of the structure defined in /usr/include/netinet/tcp.h instead of the one in the Linux header. The Linux one is different, because it includes extension fields. I originally found the problem in an example using one of those extension fields, but the warning persists if I use one of the base fields that's common between the POSIX and Linux versions.
Last edit: David Gibson 6 days ago
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just encountered an odd false positive on uninitvar. cppcheck is detecting an variable as uninitialized, although it has been set as the result of a getsockopt(). Specifically, with the attached example file:
The FP appears to be quite sensitive to the particulars:
* Removing the final pointless assignment of tinfo (correctly warned by cppcheck) removes the uninitvar warning
* Setting
tinfo = NULLrather than passing as a parameter removes the warningLast edit: David Gibson 6 days ago
Sorry, forgot to mention, this occurred with cppcheck 2.18.3 (installed from Fedora package cppcheck-2.18.3-1.fc42.x86_64).
Does this happen without
--include=/usr/include/linux/tcp.h?It does not. It does appear if I replace the
--includewith-I /usr/includeso cppcheck can find the header that way. That also triggers a bunch of other warnings from headers, though.The warning also appears if I don't include that header, but locally define
struct tcp_info. The bug originally appeared that way, but it's a large structure, so I used the header for brevity,The warning does not appear if I use the version of the structure defined in
/usr/include/netinet/tcp.hinstead of the one in the Linux header. The Linux one is different, because it includes extension fields. I originally found the problem in an example using one of those extension fields, but the warning persists if I use one of the base fields that's common between the POSIX and Linux versions.Last edit: David Gibson 6 days ago
Please include the struct definition that reproduces the error.