AI review of 2026-10-05_16-52-33-1556569a078c-results.txt PR: #8919 https://github.com/cppcheck-opensource/cppcheck/pull/8919 Tested: 1556569a078cc1617fdcbfda7ca29c196e2d1738 Merge base: 2c6098ded748110d507ae23d6a2ea2b56da130bb Reviewed: 2026-10-08 08:29:12 UTC Model: claude-opus-5-5 (effort high) Results: 44 reviewed of 44 in the report Verdicts: 10 improvement, 25 neutral, 6 regression, 3 unclear Tokens: 199484 input, 102856 cache read, 2392 cache write, 24057 output The verdicts are written by AI and can be wrong. ---- 1 / 44 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/b/binutils-gold/binutils-gold_2.44.orig.tar.xz Result: main binutils-gold-2.44/gold/testsuite/ifuncmain1.c:48:9: style: Condition 'p!=foo' is always false [knownConditionTrueFalse] binutils-gold-2.44/gold/testsuite/ifuncmain1.c:47:17: note: Calling function 'get_foo_p' returns 1 binutils-gold-2.44/gold/testsuite/ifuncmain1.c:47:17: note: Assignment 'p=get_foo_p()', assigned value is 1 binutils-gold-2.44/gold/testsuite/ifuncmain1.c:48:9: note: Condition 'p!=foo' is always false Explanation: get_foo_p() is an extern function with unknown return value. Main wrongly inferred that it 'returns 1': it treated any token with tok->function() as a bool context and assigned the value 1 (non-null). It then compared that with the function name 'foo', which also got value 1, and concluded 'p!=foo' is always false. The comparison checks whether two pointers are equal, not whether p is null, so the warning was a false positive. The PR only infers a non-null value when the function token is actually used as a bool, which removes this false positive. ---- 2 / 44 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/b/binutils-gold/binutils-gold_2.44.orig.tar.xz Result: main binutils-gold-2.44/gold/testsuite/ifuncmain1.c:58:9: style: Condition 'p!=foo_protected' is always false [knownConditionTrueFalse] binutils-gold-2.44/gold/testsuite/ifuncmain1.c:57:27: note: Calling function 'get_foo_protected_p' returns 1 binutils-gold-2.44/gold/testsuite/ifuncmain1.c:57:27: note: Assignment 'p=get_foo_protected_p()', assigned value is 1 binutils-gold-2.44/gold/testsuite/ifuncmain1.c:58:9: note: Condition 'p!=foo_protected' is always false Explanation: `get_foo_protected_p()` is an extern function. Its return value is unknown, so `p != foo_protected` compares two function pointers whose values cannot be known. Main wrongly inferred a value of 1 for the function call result, because `tok->function()` alone triggered the 'non-zero' inference without the token being used as a bool. It then reported the condition as always false. The PR now requires the inference to apply only in a boolean context, which removes this false positive. ---- 3 / 44 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/b/binutils-gold/binutils-gold_2.44.orig.tar.xz Result: main binutils-gold-2.44/gold/testsuite/ifuncmain7.c:55:9: style: Condition 'p!=foo' is always false [knownConditionTrueFalse] binutils-gold-2.44/gold/testsuite/ifuncmain7.c:54:15: note: Calling function 'get_foo' returns 1 binutils-gold-2.44/gold/testsuite/ifuncmain7.c:54:15: note: Assignment 'p=get_foo()', assigned value is 1 binutils-gold-2.44/gold/testsuite/ifuncmain7.c:55:9: note: Condition 'p!=foo' is always false Explanation: `get_foo()` returns the function pointer `foo`. In main, cppcheck inferred that the function token `foo` has the integer value 1, because the old valueFlowInferCondition treated every function token as if it were used as a bool. That bogus value made `p` and `foo` both look like 1, so it reported `p != foo` as always false. The condition is actually a real comparison of two function addresses (ifunc resolution), and its result is not knowable statically. The PR now infers a non-zero value for a function token only when it really is used as a bool, so this false positive is gone. ---- 4 / 44 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/b/binutils-gold/binutils-gold_2.44.orig.tar.xz Result: main binutils-gold-2.44/ld/testsuite/ld-ifunc/ifunc-main.c:21:15: style: Condition 'bar_ptr!=bar' is always false [knownConditionTrueFalse] binutils-gold-2.44/ld/testsuite/ld-ifunc/ifunc-main.c:20:28: note: Calling function 'get_bar' returns 1 binutils-gold-2.44/ld/testsuite/ld-ifunc/ifunc-main.c:20:28: note: Assignment 'bar_ptr=get_bar()', assigned value is 1 binutils-gold-2.44/ld/testsuite/ld-ifunc/ifunc-main.c:21:15: note: Condition 'bar_ptr!=bar' is always false Explanation: get_bar() returns the function pointer 'bar'. Main wrongly gave the token 'bar' a value of 1 (non-null inferred for any function token) and also gave bar_ptr the value 1 from 'return bar'. It then compared 1 != 1 and reported the condition as always false. Comparing a pointer with another function's address is not decidable this way, and the abort check is meaningful at runtime for ifunc resolution. The PR now only infers a non-null value when the function is used as a bool, so this false positive is gone. ---- 5 / 44 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/b/binutils-gold/binutils-gold_2.44.orig.tar.xz Result: main binutils-gold-2.44/ld/testsuite/ld-ifunc/pr18841b.c:9:10: style: Condition 'pg!=foo_impl' is always false [knownConditionTrueFalse] binutils-gold-2.44/ld/testsuite/ld-ifunc/pr18841b.c:8:22: note: Assignment 'pg=foo', assigned value is 1 binutils-gold-2.44/ld/testsuite/ld-ifunc/pr18841b.c:9:10: note: Condition 'pg!=foo_impl' is always false Explanation: `pg` is assigned the function address `foo`. Cppcheck wrongly inferred a known value of 1 for the function token `foo`, so it thought `pg` was 1. The function name `foo_impl` was given the same value 1, which made 'pg!=foo_impl' look always false. In reality the two addresses are compared at runtime, and with the ifunc resolver the result really depends on linking. The warning was a false positive. The PR only infers a non-null value for a function when it is used as a bool, so the bogus warning goes away. ---- 6 / 44 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/b/binutils-gold/binutils-gold_2.44.orig.tar.xz Result: main binutils-gold-2.44/ld/testsuite/ld-ifunc/pr29216.c:41:9: style: Condition 'p!=foo' is always false [knownConditionTrueFalse] binutils-gold-2.44/ld/testsuite/ld-ifunc/pr29216.c:40:15: note: Calling function 'get_foo' returns 1 binutils-gold-2.44/ld/testsuite/ld-ifunc/pr29216.c:40:15: note: Assignment 'p=get_foo()', assigned value is 1 binutils-gold-2.44/ld/testsuite/ld-ifunc/pr29216.c:41:9: note: Condition 'p!=foo' is always false Explanation: get_foo() returns the function address 'foo'. Main inferred a known value of 1 for the bare function token 'foo' even though it was not used as a bool. It then propagated that into p and concluded 'p!=foo' compares 1 with 1, so the condition is always false. That reasoning is bogus: p and foo both hold a function address, not the integer 1. The PR only infers a non-null value for function tokens when they are used as a bool. The false positive with its incorrect 'returns 1' notes is gone. ---- 7 / 44 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/libf/libffi/libffi_3.8.0.orig.tar.gz Result: main libffi-3.8.0/src/microblaze/ffi.c:298:25: style: Operator '|' with one operand equal to zero is redundant. [badBitmaskCheck] Explanation: `fn` holds the address of the function `ffi_closure_SYSV`, cast to `unsigned long`, so `(fn >> 16) & 0xffff` is not known to be zero. The badBitmaskCheck warning in main was a false positive. It came from main inferring values for every function-name token, even when the token was not used as a boolean. The PR limits that inference to boolean uses, so the bogus warning is gone. ---- 8 / 44 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/libf/libffi/libffi_3.8.0.orig.tar.gz Result: main libffi-3.8.0/src/sh64/ffi.c:323:25: style: Operator '|' with one operand equal to zero is redundant. [badBitmaskCheck] Explanation: Line 323 builds a trampoline instruction: `0xcc000010 | ((UINT32)ffi_closure_SYSV >> 16) << 10`. The right operand comes from a function's address, which is not known to be zero, so the '|' is not redundant and main's badBitmaskCheck was a false positive. Main applied condition inference to any function token, even one not used as a bool. That gave a bogus value that propagated through the cast and shift. The PR limits this inference to function tokens used as a bool, so the false positive is gone. ---- 9 / 44 ---- Verdict: NEUTRAL (low confidence) Package: https://ftp.debian.org/debian/pool/main/s/sipxtapi/sipxtapi_3.3.0~test18+dfsg.1.orig.tar.xz Result: main sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:146:14: style: Condition 'pTask!=NULL' is always true [knownConditionTrueFalse] sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:144:26: note: Assignment 'pTask=spOsSysLogTask', assigned value is 1 sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:146:14: note: Condition 'pTask!=NULL' is always true Explanation: In shutdown(), `pTask` is copied from the static member `spOsSysLogTask`. That member can be NULL, for example before initialize() or after an earlier shutdown(). So 'pTask!=NULL is always true' is a false positive; the 'assigned value is 1' note shows Cppcheck wrongly infers a known non-null value. The PR does not remove this warning: the same warning at line 146 appears again as a 'your' line, so it is only re-reported, probably with changed notes. The false positive stays either way, and since the new notes are not shown, there is no visible gain or loss for users. ---- 10 / 44 ---- Verdict: NEUTRAL (low confidence) Package: https://ftp.debian.org/debian/pool/main/s/sipxtapi/sipxtapi_3.3.0~test18+dfsg.1.orig.tar.xz Result: main sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:170:22: style: Condition 'pOsSysLogTask!=NULL' is always true [knownConditionTrueFalse] sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:168:34: note: Assignment 'pOsSysLogTask=spOsSysLogTask', assigned value is 1 sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:170:22: note: Condition 'pOsSysLogTask!=NULL' is always true Explanation: The same knownConditionTrueFalse warning for 'pOsSysLogTask!=NULL' at line 170 is reported by both main and the PR, so only the attached notes can differ, and the PR's notes are not shown. In the code, pOsSysLogTask is copied from the static pointer spOsSysLogTask, which shutdown() sets to NULL. The main note 'assigned value is 1' is therefore bogus and the warning is a false positive either way. The PR neither removes nor fixes it, so for users the effect is essentially neutral. Without the new notes, it cannot be judged whether the message got better or worse. ---- 11 / 44 ---- Verdict: UNCLEAR (low confidence) Package: https://ftp.debian.org/debian/pool/main/s/sipxtapi/sipxtapi_3.3.0~test18+dfsg.1.orig.tar.xz Result: main sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:198:22: style: Condition 'pOsSysLogTask!=NULL' is always true [knownConditionTrueFalse] sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:196:34: note: Assignment 'pOsSysLogTask=spOsSysLogTask', assigned value is 1 sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:198:22: note: Condition 'pOsSysLogTask!=NULL' is always true Explanation: The PR version reports the same warning at the same line with the same message, so only the attached notes changed, and the new notes are not shown. In the code, `pOsSysLogTask` is copied from `spOsSysLogTask`, which looks like a global or static task pointer that can be NULL before initialization. The 'assigned value is 1' note therefore looks bogus, and the warning is probably a false positive in both versions. Without the new notes, it is impossible to tell whether the message became more or less accurate. ---- 12 / 44 ---- Verdict: NEUTRAL (low confidence) Package: https://ftp.debian.org/debian/pool/main/s/sipxtapi/sipxtapi_3.3.0~test18+dfsg.1.orig.tar.xz Result: main sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:218:22: style: Condition 'pOsSysLogTask!=NULL' is always true [knownConditionTrueFalse] sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:216:34: note: Assignment 'pOsSysLogTask=spOsSysLogTask', assigned value is 1 sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:218:22: note: Condition 'pOsSysLogTask!=NULL' is always true Explanation: The same warning, 'Condition pOsSysLogTask!=NULL is always true' at line 218, is reported by both main and your. Only the attached notes appear to differ, and the diff does not show your version of the notes. Either way the warning is a false positive in both versions. spOsSysLogTask is a static logger-task pointer that may be NULL until the logger is initialized, so the NULL check is meaningful, and 'assigned value is 1' is bogus. The PR neither removes nor adds this false positive, so the change has no user-visible effect. ---- 13 / 44 ---- Verdict: UNCLEAR (low confidence) Package: https://ftp.debian.org/debian/pool/main/s/sipxtapi/sipxtapi_3.3.0~test18+dfsg.1.orig.tar.xz Result: main sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:235:22: style: Condition 'pOsSysLogTask!=NULL' is always true [knownConditionTrueFalse] sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:233:34: note: Assignment 'pOsSysLogTask=spOsSysLogTask', assigned value is 1 sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:235:22: note: Condition 'pOsSysLogTask!=NULL' is always true Explanation: The same 'pOsSysLogTask!=NULL is always true' warning is reported by both main and your. Only the accompanying notes probably differ; the your-side notes are not shown. spOsSysLogTask is a static pointer that can legitimately be NULL, since the code checks it and falls back to OS_UNSPECIFIED. So the warning looks like a false positive in both versions. Main's note 'assigned value is 1' reflects the old bug where any token with function() got a bogus inferred value. Without the new note text, it cannot be decided whether the message became more or less accurate. ---- 14 / 44 ---- Verdict: NEUTRAL (low confidence) Package: https://ftp.debian.org/debian/pool/main/s/sipxtapi/sipxtapi_3.3.0~test18+dfsg.1.orig.tar.xz Result: main sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:261:22: style: Condition 'pOsSysLogTask!=NULL' is always true [knownConditionTrueFalse] sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:260:34: note: Assignment 'pOsSysLogTask=spOsSysLogTask', assigned value is 1 sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:261:22: note: Condition 'pOsSysLogTask!=NULL' is always true Explanation: Both main and the PR report the same warning, 'pOsSysLogTask!=NULL' is always true, at line 261. The line shows up as a diff only because the attached notes probably differ slightly, and the PR's notes are not shown. The finding itself is unchanged, so users see no meaningful difference. Note that the warning looks dubious in both versions: spOsSysLogTask is a static that is presumably NULL until the log task is initialized, and an 'assigned value is 1' is not a plausible value for it. The PR neither fixes nor causes that. ---- 15 / 44 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/s/sipxtapi/sipxtapi_3.3.0~test18+dfsg.1.orig.tar.xz Result: main sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:280:25: style: Condition 'pOsSysLogTask!=NULL' is always true [knownConditionTrueFalse] sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:279:37: note: Assignment 'pOsSysLogTask=spOsSysLogTask', assigned value is 1 sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:280:25: note: Condition 'pOsSysLogTask!=NULL' is always true Explanation: The same warning, 'pOsSysLogTask!=NULL' is always true at line 280, is reported by both main and your. Only the accompanying note/trace differs. The warning itself looks like a false positive in both versions: `spOsSysLogTask` is a static pointer that can be NULL, and the 'assigned value is 1' claim is dubious. The PR neither removes nor adds it, so users see no meaningful change. ---- 16 / 44 ---- Verdict: NEUTRAL (low confidence) Package: https://ftp.debian.org/debian/pool/main/s/sipxtapi/sipxtapi_3.3.0~test18+dfsg.1.orig.tar.xz Result: main sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:474:33: style: Condition 'pOsSysLogTask!=NULL' is always true [knownConditionTrueFalse] sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:473:44: note: Assignment 'pOsSysLogTask=spOsSysLogTask', assigned value is 1 sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:474:33: note: Condition 'pOsSysLogTask!=NULL' is always true Explanation: The same warning, with identical text at the same location (474:33, 'pOsSysLogTask!=NULL' is always true), is reported by both main and the PR. The diff pairs one main line with one your line, so the difference is probably only in the note lines, which are not shown for the PR version. The warning itself is doubtful because spOsSysLogTask is a global/static pointer that can be NULL, but the PR neither adds nor removes it. For users the change has no visible effect. ---- 17 / 44 ---- Verdict: NEUTRAL (low confidence) Package: https://ftp.debian.org/debian/pool/main/s/sipxtapi/sipxtapi_3.3.0~test18+dfsg.1.orig.tar.xz Result: main sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:495:22: style: Condition 'pOsSysLogTask!=NULL' is always true [knownConditionTrueFalse] sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:494:34: note: Assignment 'pOsSysLogTask=spOsSysLogTask', assigned value is 1 sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:495:22: note: Condition 'pOsSysLogTask!=NULL' is always true Explanation: The same knownConditionTrueFalse warning for 'pOsSysLogTask!=NULL' at line 495 is reported by both main and the PR, with identical text. Only the attached note details can differ, and the PR's notes are not shown. The warning itself looks like a false positive: spOsSysLogTask is a static or global task pointer that can be NULL, and the 'assigned value is 1' looks like a bogus inferred value. However, the PR neither removes nor adds this warning, so users see no meaningful difference. ---- 18 / 44 ---- Verdict: UNCLEAR (low confidence) Package: https://ftp.debian.org/debian/pool/main/s/sipxtapi/sipxtapi_3.3.0~test18+dfsg.1.orig.tar.xz Result: main sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:511:22: style: Condition 'pOsSysLogTask!=NULL' is always true [knownConditionTrueFalse] sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:510:34: note: Assignment 'pOsSysLogTask=spOsSysLogTask', assigned value is 1 sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:511:22: note: Condition 'pOsSysLogTask!=NULL' is always true Explanation: Both main and the PR report the same 'pOsSysLogTask!=NULL is always true' warning at line 511; only main's version, with the note 'assigned value is 1', is listed as removed. The PR's replacement is reported with the same headline, so only the supporting notes probably changed, and we cannot see them. The warning itself looks like a false positive in both versions: spOsSysLogTask is a static task pointer that can be NULL, and 'assigned value is 1' makes no sense for it. Without the new notes or the declaration of spOsSysLogTask, we cannot tell whether the message became more or less accurate. ---- 19 / 44 ---- Verdict: NEUTRAL (low confidence) Package: https://ftp.debian.org/debian/pool/main/s/sipxtapi/sipxtapi_3.3.0~test18+dfsg.1.orig.tar.xz Result: main sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:575:22: style: Condition 'pOsSysLogTask!=NULL' is always true [knownConditionTrueFalse] sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:574:34: note: Assignment 'pOsSysLogTask=spOsSysLogTask', assigned value is 1 sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:575:22: note: Condition 'pOsSysLogTask!=NULL' is always true Explanation: The same warning, 'pOsSysLogTask!=NULL' is always true at line 575, is reported by both main and your. Only the main line and its notes are shown, so the difference is probably confined to the attached notes, which are not visible for the 'your' side. The warning itself is likely a false positive: the code copies a static global task pointer that can be NULL before initialization, and the note 'assigned value is 1' is dubious. However, the PR neither adds nor removes it, so user-visible output is essentially unchanged. ---- 20 / 44 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/s/sipxtapi/sipxtapi_3.3.0~test18+dfsg.1.orig.tar.xz Result: main sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:591:22: style: Condition 'pOsSysLogTask!=NULL' is always true [knownConditionTrueFalse] sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:590:34: note: Assignment 'pOsSysLogTask=spOsSysLogTask', assigned value is 1 sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:591:22: note: Condition 'pOsSysLogTask!=NULL' is always true Explanation: Both main and the PR report the same warning, 'pOsSysLogTask!=NULL' is always true, at line 591. The main/your pair only reflects a change in the attached notes, not in the warning. In the code, `pOsSysLogTask` is copied from the static `spOsSysLogTask`, which can be NULL before initialization, so the warning looks like a false positive in both versions. The PR neither removes nor adds a diagnostic here, so users see no meaningful difference. ---- 21 / 44 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/s/sipxtapi/sipxtapi_3.3.0~test18+dfsg.1.orig.tar.xz Result: main sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:608:22: style: Condition 'pOsSysLogTask!=NULL' is always true [knownConditionTrueFalse] sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:607:34: note: Assignment 'pOsSysLogTask=spOsSysLogTask', assigned value is 1 sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:608:22: note: Condition 'pOsSysLogTask!=NULL' is always true Explanation: Main and the PR report the same knownConditionTrueFalse warning at OsSysLog.cpp:608:22, with the same text and notes. The diff pairs one 'main' line with an identical 'your' line, so nothing changed for users. The warning itself looks dubious: 'assigned value is 1' for the static pointer spOsSysLogTask is suspicious. However, the PR neither added nor removed it. ---- 22 / 44 ---- Verdict: NEUTRAL (low confidence) Package: https://ftp.debian.org/debian/pool/main/s/sipxtapi/sipxtapi_3.3.0~test18+dfsg.1.orig.tar.xz Result: main sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:627:22: style: Condition 'pOsSysLogTask!=NULL' is always true [knownConditionTrueFalse] sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:626:34: note: Assignment 'pOsSysLogTask=spOsSysLogTask', assigned value is 1 sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:627:22: note: Condition 'pOsSysLogTask!=NULL' is always true Explanation: Both main and your report the same 'pOsSysLogTask!=NULL is always true' warning at 627:22. Only the attached notes appear to differ, so the user-visible headline warning is unchanged. The warning looks like a false positive in both versions: spOsSysLogTask is a static task pointer that can be NULL before the logger is initialized, so the null check is legitimate. The PR neither removes nor adds it, it only changes how the value is traced. ---- 23 / 44 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/s/sipxtapi/sipxtapi_3.3.0~test18+dfsg.1.orig.tar.xz Result: your sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:146:14: style: Condition 'pTask!=NULL' is always true [knownConditionTrueFalse] Explanation: The same warning, with identical text, is reported by both main and the PR at OsSysLog.cpp:146, so only some detail such as the notes differs. The warning itself looks like a false positive in both versions. `pTask` is copied from the global `spOsSysLogTask`, which is NULL until `initialize()` runs and is reset to NULL in `shutdown()`, so `pTask != NULL` is a real runtime check. The PR neither adds nor removes this report, so users see no change. ---- 24 / 44 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/s/sipxtapi/sipxtapi_3.3.0~test18+dfsg.1.orig.tar.xz Result: your sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:170:22: style: Condition 'pOsSysLogTask!=NULL' is always true [knownConditionTrueFalse] Explanation: The same warning, 'pOsSysLogTask!=NULL' is always true at line 170, is reported by both main and the PR. Only its pairing in the diff output differs, probably from a change in the supporting notes. The warning itself is a false positive in both versions: spOsSysLogTask is a static pointer that can be NULL (shutdown() sets it to NULL), and the 'assigned value is 1' note is bogus. The PR neither fixes nor introduces the false positive, so nothing changes for users. ---- 25 / 44 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/s/sipxtapi/sipxtapi_3.3.0~test18+dfsg.1.orig.tar.xz Result: your sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:198:22: style: Condition 'pOsSysLogTask!=NULL' is always true [knownConditionTrueFalse] Explanation: Main and the PR report exactly the same message at OsSysLog.cpp:198:22 ('pOsSysLogTask!=NULL' is always true). Whatever differs between the two runs, such as note details or ordering, is not visible here. The warning itself looks dubious: spOsSysLogTask is a static task pointer that can be NULL before initialization, so 'assigned value is 1' is suspicious. Still, the PR neither adds nor removes it, and the user-visible output is unchanged. ---- 26 / 44 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/s/sipxtapi/sipxtapi_3.3.0~test18+dfsg.1.orig.tar.xz Result: your sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:218:22: style: Condition 'pOsSysLogTask!=NULL' is always true [knownConditionTrueFalse] Explanation: Main and the PR report the same warning, with identical text and notes, at OsSysLog.cpp:218. The diff line probably comes from a tiny formatting or ordering difference, not a change in what is reported. The warning is likely a false positive: `spOsSysLogTask` is a static task pointer that can be NULL before initialization, and the claimed 'assigned value is 1' looks bogus. But the PR neither adds nor removes it, so users see no change. ---- 27 / 44 ---- Verdict: NEUTRAL (low confidence) Package: https://ftp.debian.org/debian/pool/main/s/sipxtapi/sipxtapi_3.3.0~test18+dfsg.1.orig.tar.xz Result: your sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:235:22: style: Condition 'pOsSysLogTask!=NULL' is always true [knownConditionTrueFalse] Explanation: The same knownConditionTrueFalse warning for 'pOsSysLogTask!=NULL' at line 235 is reported by both main and the PR. Every other function in this file shows the same main/your pair, so the difference is probably only in the attached notes or other metadata, not in the warning itself. The warning looks dubious: spOsSysLogTask is a static logger task pointer that can be NULL before initialization, and the note 'assigned value is 1' is suspicious. Still, the PR neither introduces nor removes it. For users the result is effectively unchanged. ---- 28 / 44 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/s/sipxtapi/sipxtapi_3.3.0~test18+dfsg.1.orig.tar.xz Result: your sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:261:22: style: Condition 'pOsSysLogTask!=NULL' is always true [knownConditionTrueFalse] Explanation: The same knownConditionTrueFalse warning at OsSysLog.cpp:261 is reported by both main and the PR, with identical text and the same shared notes. The 'your' line only pairs with an identical 'main' line, so it is an output ordering or duplication artifact, not a real behaviour change. The warning itself is doubtful: spOsSysLogTask is a global that can be NULL, yet Cppcheck claims it was assigned 1. But that is not something this PR introduced or removed. ---- 29 / 44 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/s/sipxtapi/sipxtapi_3.3.0~test18+dfsg.1.orig.tar.xz Result: your sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:280:25: style: Condition 'pOsSysLogTask!=NULL' is always true [knownConditionTrueFalse] Explanation: Main and the PR report the same warning at OsSysLog.cpp:280:25 with identical text, and the notes are shared, so the result is effectively unchanged. The warning itself looks like a false positive in both versions. `spOsSysLogTask` is a static task pointer that is normally NULL until the log is initialized, so the claim 'assigned value is 1' is bogus. The PR neither introduces nor removes it, so it makes no difference to users. ---- 30 / 44 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/s/sipxtapi/sipxtapi_3.3.0~test18+dfsg.1.orig.tar.xz Result: your sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:474:33: style: Condition 'pOsSysLogTask!=NULL' is always true [knownConditionTrueFalse] Explanation: Main and the PR report exactly the same message at line 474:33, with the same text and the same notes. The pair only shows up because of a formatting or ordering difference in the comparison. Whatever the merits of the warning itself (spOsSysLogTask is a static pointer, and 'assigned value is 1' looks doubtful), the PR neither adds nor removes it for users. ---- 31 / 44 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/s/sipxtapi/sipxtapi_3.3.0~test18+dfsg.1.orig.tar.xz Result: your sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:495:22: style: Condition 'pOsSysLogTask!=NULL' is always true [knownConditionTrueFalse] Explanation: Main and the PR report the same 'pOsSysLogTask!=NULL is always true' warning at the same location, with the same message and the same notes. The diff is only a re-listing of an existing warning, not a real addition or removal. The warning itself looks dubious: it rests on spOsSysLogTask having the value 1, while the code clearly allows it to be NULL. But the PR neither introduces nor fixes it. ---- 32 / 44 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/s/sipxtapi/sipxtapi_3.3.0~test18+dfsg.1.orig.tar.xz Result: your sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:511:22: style: Condition 'pOsSysLogTask!=NULL' is always true [knownConditionTrueFalse] Explanation: Both main and the PR report the same warning at line 511 with identical text. Only an associated detail (such as the note chain or ordering) differs, so nothing changes for users. The warning itself is probably a false positive in both versions: 'assigned value is 1' for a static task pointer that is checked against NULL looks wrong. But the PR neither adds nor removes it. ---- 33 / 44 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/s/sipxtapi/sipxtapi_3.3.0~test18+dfsg.1.orig.tar.xz Result: your sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:575:22: style: Condition 'pOsSysLogTask!=NULL' is always true [knownConditionTrueFalse] Explanation: The same knownConditionTrueFalse warning for 'pOsSysLogTask!=NULL' at line 575 is reported by both main and the PR with identical text. The diff entry comes from reporting or ordering noise, not from a change in what is detected. Whether the warning is correct (the 'assigned value is 1' for spOsSysLogTask looks suspicious) does not change with this PR, so users see no difference. ---- 34 / 44 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/s/sipxtapi/sipxtapi_3.3.0~test18+dfsg.1.orig.tar.xz Result: your sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:591:22: style: Condition 'pOsSysLogTask!=NULL' is always true [knownConditionTrueFalse] Explanation: Main and the PR report the same 'pOsSysLogTask!=NULL is always true' warning at line 591, with identical text. Every other line in this package shows the same main/your pairing, so whatever differs is not visible here (probably detail in the notes). The warning itself looks dubious in both versions: spOsSysLogTask is a static task pointer that may be NULL, and 'assigned value is 1' is suspicious. Still, the PR neither adds nor removes it, so for users the result is unchanged. ---- 35 / 44 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/s/sipxtapi/sipxtapi_3.3.0~test18+dfsg.1.orig.tar.xz Result: your sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:608:22: style: Condition 'pOsSysLogTask!=NULL' is always true [knownConditionTrueFalse] Explanation: Main and the PR report the same warning at the same location with identical text, so the line shows up as a paired main/your entry with no visible change for users. The warning itself looks like a false positive in both versions. `pOsSysLogTask` is copied from the shared static `spOsSysLogTask`, which is normally NULL until the log task is created, so the `!= NULL` check is legitimate. The claimed 'assigned value is 1' does not come from this PR. The PR neither fixes nor introduces this report. ---- 36 / 44 ---- Verdict: NEUTRAL (medium confidence) Package: https://ftp.debian.org/debian/pool/main/s/sipxtapi/sipxtapi_3.3.0~test18+dfsg.1.orig.tar.xz Result: your sipXtapi-3.3.0_test18/sipXportLib/src/os/OsSysLog.cpp:627:22: style: Condition 'pOsSysLogTask!=NULL' is always true [knownConditionTrueFalse] Explanation: Main and the PR report the identical knownConditionTrueFalse warning at OsSysLog.cpp:627:22 with the same text, and the same pairing appears for every other line in this file. The reported line is just one half of a main/your pair caused by output churn, not a new finding. Whether the warning is right (the 'assigned value is 1' for the static spOsSysLogTask looks doubtful) does not depend on the PR, because both versions emit it. So the result does not matter to users either way. ---- 37 / 44 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/s/synfigstudio/synfigstudio_1.5.5.orig.tar.xz Result: main synfig-1.5.5/synfig-studio/src/gui/app.cpp:1472:18: style: Condition 'ui_language!="os_LANG"' is always true [knownConditionTrueFalse] Explanation: `ui_language` is a static string that `load_language_settings()` fills from the user settings. It can be "os_LANG" (the OS-default choice), so `ui_language != "os_LANG"` is not always true and the warning was a false positive. The old code ran condition inference on any token whose `function()` was set, here likely the overloaded `operator!=`. That produced a wrong known value. The PR limits that inference to function tokens actually used as a bool, which removes this false positive. ---- 38 / 44 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/z/zile/zile_2.6.2.orig.tar.gz Result: main src/buffer.vala:596:31: style: Condition 'func_target_destroy_notify==NULL' is always false [knownConditionTrueFalse] src/buffer.vala:593:31: note: Assignment 'func_target_destroy_notify=buffer_unref', assigned value is 1 src/buffer.vala:594:8: note: Assuming condition is true src/buffer.vala:596:31: note: Condition 'func_target_destroy_notify==NULL' is always false Explanation: Cppcheck analyzed the Vala-generated C code. There, `func_target_destroy_notify` is assigned the function `buffer_unref` and is later compared with NULL. A function address is never null, so 'always false' is correct. The PR stops inferring non-null for such function-pointer variables when the pointer type is not recognized (here likely a typedef like GDestroyNotify). The PR's own test turns the analogous `q==nullptr` case into a TODO, so it knowingly drops this true positive. Because the code is generated, users may not act on the warning, but it is still a lost true positive. ---- 39 / 44 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/z/zile/zile_2.6.2.orig.tar.gz Result: main src/funcs.vala:100:32: style: Condition '_tmp2__target_destroy_notify==NULL' is always false [knownConditionTrueFalse] src/funcs.vala:100:33: note: Assignment '_tmp2__target_destroy_notify=buffer_unref', assigned value is 1 src/funcs.vala:100:32: note: Condition '_tmp2__target_destroy_notify==NULL' is always false Explanation: The Vala source compiles to C, where `_tmp2__target_destroy_notify` is assigned the function `buffer_unref` and later checked against NULL (the usual Vala destroy-notify pattern). A function address is never NULL, so 'always false' is technically correct. The PR makes inference for function tokens depend on isUsedAsBool, which drops this case. The PR's own test turns the matching `q = g; if (q == nullptr)` warning into a TODO, confirming this is a lost true positive. It is low-value noise in generated code, but still a regression. ---- 40 / 44 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/z/zile/zile_2.6.2.orig.tar.gz Result: main src/funcs.vala:104:32: style: Condition '_tmp7__target_destroy_notify==NULL' is always false [knownConditionTrueFalse] src/funcs.vala:104:33: note: Assignment '_tmp7__target_destroy_notify=buffer_unref', assigned value is 1 src/funcs.vala:104:32: note: Condition '_tmp7__target_destroy_notify==NULL' is always false Explanation: The report is on Vala-generated C code. There `_tmp7__target_destroy_notify` is assigned the function address `buffer_unref` and then compared with NULL, typically in the cleanup expression `(x == NULL) ? NULL : (x(target), NULL)`. A function address is never NULL, so 'always false' is technically correct. The PR now infers a non-zero value for a function token only when `isUsedAsBool` holds. That no longer covers a function pointer variable that merely holds a function address and is compared to NULL. The PR's own test change makes the analogous `q == nullptr` case a TODO. So a true positive is lost, although it is in generated code. ---- 41 / 44 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/z/zile/zile_2.6.2.orig.tar.gz Result: main src/funcs.vala:119:34: style: Condition '_tmp13__target_destroy_notify==NULL' is always false [knownConditionTrueFalse] src/funcs.vala:119:35: note: Assignment '_tmp13__target_destroy_notify=buffer_unref', assigned value is 1 src/funcs.vala:119:34: note: Condition '_tmp13__target_destroy_notify==NULL' is always false Explanation: The Vala file maps to Vala-generated C. That C assigns the function address `buffer_unref` to `_tmp13__target_destroy_notify` and then compares it with NULL. A function's address is never NULL, so 'Condition ... ==NULL is always false' is a true positive, even though it sits in generated code. The PR now infers non-null for function tokens only when `isUsedAsBool` holds, and loses this case once the function is copied into a variable. The PR itself turns the `q = g; if (q == nullptr)` test into a TODO, admitting the lost detection. Removing this true positive is a regression. ---- 42 / 44 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/z/zile/zile_2.6.2.orig.tar.gz Result: main src/funcs.vala:150:33: style: Condition '_tmp30__target_destroy_notify==NULL' is always false [knownConditionTrueFalse] src/funcs.vala:150:34: note: Assignment '_tmp30__target_destroy_notify=buffer_unref', assigned value is 1 src/funcs.vala:150:33: note: Condition '_tmp30__target_destroy_notify==NULL' is always false Explanation: Line 150 is Vala source; the warning comes from the generated C code. That code assigns `_tmp30__target_destroy_notify = buffer_unref` and then tests `_tmp30__target_destroy_notify == NULL`. A function address is never null, so the condition really is always false and the warning was a true positive. Main reached it by wrongly giving the function token a known value of 1, which is why the note says 'assigned value is 1'. The PR fixes that bad value but loses the true positive. The PR itself admits this by turning the matching `q==nullptr` test case into a TODO. The finding is in generated code, so its practical value is limited, but a correct warning was removed. ---- 43 / 44 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/z/zile/zile_2.6.2.orig.tar.gz Result: main src/funcs.vala:172:14: style: Condition '_tmp46_!=NULL' is always false [knownConditionTrueFalse] src/funcs.vala:148:8: note: Assignment 'es2=NULL', assigned value is 0 src/funcs.vala:172:12: note: Assignment '_tmp46_=es2', assigned value is 0 src/funcs.vala:172:14: note: Condition '_tmp46_!=NULL' is always false Explanation: `es2` starts as null at line 148, but the else branch at line 161 assigns it `Estr.of_empty(...)`. So `es2 != null` at line 172 depends on which branch ran and is not always false. Main reached its conclusion because the old code gave any token with `tok->function()` a non-zero value, even when it was only an operand of a function-pointer comparison. That apparently made the `move_func == cur_bp.move_line` condition at line 150 look known, and the path that leaves `es2` null looked like the only one. The PR now applies this inference only when the function is actually used as a bool, which removes this false positive. ---- 44 / 44 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/z/zile/zile_2.6.2.orig.tar.gz Result: main src/funcs.vala:183:33: style: Condition '_tmp56__target_destroy_notify==NULL' is always false [knownConditionTrueFalse] src/funcs.vala:183:34: note: Assignment '_tmp56__target_destroy_notify=buffer_unref', assigned value is 1 src/funcs.vala:183:33: note: Condition '_tmp56__target_destroy_notify==NULL' is always false Explanation: In the Vala-generated C, `_tmp56__target_destroy_notify` is a function pointer assigned the address of the function `buffer_unref`. The address of a function is never NULL, so the generated check `_tmp56__target_destroy_notify == NULL` really is always false. The removed warning was therefore a true positive. The PR knowingly loses this case: the testcondition change turns the `auto q = g; if (q == nullptr)` expectation into a TODO, which is the same function-pointer-copied-to-variable pattern. The note text "assigned value is 1" was imprecise, but the conclusion was correct. The code is generated and the check is harmless, so users may not care much, but losing a correct diagnostic is a regression.