AI review of 2025-12-14_14-17-35-06df4cf3c3ab-results.txt PR: #8028 https://github.com/cppcheck-opensource/cppcheck/pull/8028 Tested: 06df4cf3c3abbc8465639f1ff1d129ed9227b4c8 Merge base: 40cf3c3192b32442a9c707fa0b0cb841f7198874 Reviewed: 2026-10-07 20:26:37 UTC Model: claude-opus-5-5 (effort high) Results: 50 reviewed of 83 in the report (random sample) Verdicts: 15 improvement, 35 regression Tokens: 180695 input, 141218 cache read, 2882 cache write, 35615 output The verdicts are written by AI and can be wrong. ---- 1 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/h/hedgewars/hedgewars_1.0.3.orig.tar.bz2 Result: main hedgewars-src-1.0.3/project_files/hwc/rtl/tests/check_system.c:233:5: warning: %lld in format string (no. 1) requires 'long long' but the argument type is 'signed long'. [invalidPrintfArgType_sint] Explanation: Line 233 passes an int64_t to printf with %lld. On LP64 Linux, int64_t is 'long', so the specifier is formally wrong there. On platforms where int64_t is 'long long' it is correct. This is a portability problem: the portable form is PRId64. Main reported it as a generic warning about 'signed long'. The PR replaces it with a portability warning naming 'int64_t {aka signed long}'. That severity and type description are more accurate, so removing the old line is part of a message-accuracy improvement. ---- 2 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/h/hedgewars/hedgewars_1.0.3.orig.tar.bz2 Result: your hedgewars-src-1.0.3/project_files/hwc/rtl/system.c:429:5: portability: %llu in format string (no. 1) requires 'unsigned long long' but the argument type is 'uint64_t {aka unsigned long}'. [invalidPrintfArgType_uint] Explanation: At line 429, `x` is a `uint64_t` passed to `%llu`. On LP64 `uint64_t` is `unsigned long` and on other platforms it is `unsigned long long`. Using `%llu` for a fixed-width typedef is therefore a portability issue, not a plain type error: the correct portable form is `PRIu64` or a cast to `unsigned long long`. The new message names the typedef ('uint64_t {aka unsigned long}') and reports it at portability severity, which describes the problem more accurately than the old generic warning about 'unsigned long'. ---- 3 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/h/hedgewars/hedgewars_1.0.3.orig.tar.bz2 Result: your hedgewars-src-1.0.3/project_files/hwc/rtl/tests/check_system.c:236:5: portability: %llu in format string (no. 1) requires 'unsigned long long' but the argument type is 'uint64_t {aka unsigned long}'. [invalidPrintfArgType_uint] Explanation: `a8` is declared as `uint64_t` and printed with `%llu`. On LP64 platforms `uint64_t` is `unsigned long`, not `unsigned long long`, so the mismatch exists only on some platforms. That makes it a portability issue rather than a real bug everywhere. The new message names the actual declared type (`uint64_t {aka unsigned long}`), and the severity is now portability instead of warning. The diagnostic is more accurate and better classified. ---- 4 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/h/hexwalk/hexwalk_1.9.1.orig.tar.gz Result: main hexwalk-1.9.1/src/hexwalk/entropydialog.cpp:136:42: warning: %lld in format string (no. 1) requires 'long long' but the argument type is 'signed long'. [invalidPrintfArgType_sint] Explanation: `address` is a `qint64`, which Qt defines as `qlonglong` (`long long`), so printing it with `%lld` is correct. Main's warning that the argument is a 'signed long' comes from cppcheck's library modelling `qint64` as long. It was a false positive at warning severity. With the PR, the library type name is kept, so the message is replaced by a portability-severity one that names the type (`qint64 {aka signed long}`). Removing the incorrect warning-level report and replacing it with a more accurate, lower-severity message is an improvement, even if the portability report is still debatable. ---- 5 / 50 ---- Verdict: REGRESSION (low confidence) Package: https://ftp.debian.org/debian/pool/main/h/hexwalk/hexwalk_1.9.1.orig.tar.gz Result: main hexwalk-1.9.1/src/qhexedit/qhexedit.cpp:974:29: style: int result is assigned to long variable. If the variable is long to avoid loss of information, then you have loss of information. [truncLongCastAssignment] Explanation: Line 974 computes `row * _bytesPerLine` in `int` and stores it in a `qint64`. That is exactly the pattern `truncLongCastAssignment` targets. In practice the values here are small (visible rows times bytes per line), so the warning is not a real bug, but it is a valid style finding. The PR now records the library typedef name (`qint64`) as `originalTypeName`. That side effect makes the check skip this assignment, even though the underlying types did not change. Losing a valid finding as an unintended side effect is mildly negative. If the check is meant to ignore typedef'd targets, this would be neutral instead, hence low confidence. ---- 6 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/i/iat/iat_0.1.7.orig.tar.bz2 Result: main iat-0.1.7/src/debug.c:220:2: warning: %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'. [invalidPrintfArgType_sint] Explanation: Line 220 prints `udf_pvd->primary_volume_description_number` (a `uint32_t`) with `%d`. That is a signedness mismatch on every platform, because `uint32_t` is always unsigned, so main's `warning` is a true positive. The PR replaces it with the same finding at `portability` severity. The text is nicer ('uint32_t {aka unsigned int}'), but the issue is not platform-dependent. Portability checks are off by default, so users with default settings lose a valid warning. The PR's own TODO admits that fixed-width types are now handled wrongly in `getSeverity`. Net effect: a correct warning was downgraded to a less accurate severity. ---- 7 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/i/iat/iat_0.1.7.orig.tar.bz2 Result: main iat-0.1.7/src/debug.c:234:2: warning: %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'. [invalidPrintfArgType_sint] Explanation: `vol_abstract.len` is a `uint32_t` printed with `%d`. That is a signedness mismatch on every platform, because `uint32_t` is always unsigned. Main's warning was a true positive at warning severity. The PR replaces it with a portability-severity message. The new text names the type better (`uint32_t {aka unsigned int}`), but the severity is now wrong: this is not a platform-dependent issue. Portability messages are also off by default, so users lose the finding unless they enable portability checks. The PR's own TODO admits that fixed-width types are mishandled by `getSeverity`. ---- 8 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/i/iat/iat_0.1.7.orig.tar.bz2 Result: your iat-0.1.7/src/debug.c:234:2: portability: %d in format string (no. 1) requires 'int' but the argument type is 'uint32_t {aka unsigned int}'. [invalidPrintfArgType_sint] Explanation: `vol_abstract.len` is a `uint32_t` and is printed with `%d`. That signed/unsigned mismatch is wrong on every platform, not just some, so this is a real bug. Main reported it as a `warning`. With the PR the message names the type more accurately (`uint32_t {aka unsigned int}`). However, the severity drops to `portability`, which is off by default, so most users will no longer see this true positive. The PR itself adds a TODO admitting that fixed-width types like `int32_t` are not handled properly here. The clearer type name does not make up for effectively hiding a real bug. ---- 9 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libs/libsepol/libsepol_3.11.orig.tar.gz Result: main libsepol-3.11/cil/src/cil_policy.c:1840:3: warning: %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'. [invalidPrintfArgType_sint] Explanation: `pkey_low` is a `uint32_t` (always unsigned int) printed with `%d`. That is a real signedness mismatch on every platform, and main reported it at warning severity. The PR replaces it with a portability-severity message. The new text shows the typedef name, which is nicer, but the severity is now wrong. A uint32_t vs %d sign mismatch is not a platform-dependent portability issue. Portability checks are often disabled by default, so users lose this true positive. The PR's own TODO admits the fixed-width typedef handling is wrong. ---- 10 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libs/libsepol/libsepol_3.11.orig.tar.gz Result: main libsepol-3.11/cil/src/cil_policy.c:1841:3: warning: %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'. [invalidPrintfArgType_sint] Explanation: `pkey_high` is a `uint32_t` printed with `%d`. That is a signedness mismatch on every platform, not a platform-dependent issue. Main reported it as a warning, which is enabled by default. With the PR, the type now carries the original name `uint32_t`, so `getSeverity()` downgrades the report to portability. Portability is off by default, so most users stop seeing a genuine type mismatch. The new text ('uint32_t {aka unsigned int}') is nicer, but the severity is wrong for a fixed-width type. The PR's own TODO admits that fixed-width types are handled incorrectly. Overall this removes a default-visible true positive. ---- 11 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libs/libsepol/libsepol_3.11.orig.tar.gz Result: main libsepol-3.11/cil/src/cil_policy.c:1882:4: warning: %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'. [invalidPrintfArgType_sint] Explanation: `portcon->port_low` is a `uint32_t` printed with `%d`. The mismatch is real and is still reported. The pull request replaces the generic warning with a portability message that names the typedef: 'uint32_t {aka unsigned int}'. This matches how Cppcheck already treats library typedefs such as size_t. The new text is more accurate. Port values (0–65535) print correctly through `%d`, so the lower severity is reasonable. The catch is that portability messages are off by default, so default runs no longer show it. ---- 12 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libs/libsepol/libsepol_3.11.orig.tar.gz Result: main libsepol-3.11/cil/src/cil_policy.c:1884:4: warning: %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'. [invalidPrintfArgType_sint] Explanation: `portcon->port_low` and `port_high` are `uint32_t` and are printed with `%d`. That is a signed/unsigned mismatch on every platform, because `uint32_t` is always unsigned. Main reported it as a warning. With the PR the same issue is reported at portability severity, only because the type now has an original typedef name (`uint32_t`). The 'aka' text is a bit more informative. But the severity is now wrong, since this is not platform-dependent, and portability is often not enabled, so users running with warnings only lose a valid finding. The PR's own TODO admits fixed-width types are mishandled. ---- 13 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libs/libsepol/libsepol_3.11.orig.tar.gz Result: main libsepol-3.11/cil/src/cil_policy.c:1884:4: warning: %d in format string (no. 2) requires 'int' but the argument type is 'unsigned int'. [invalidPrintfArgType_sint] Explanation: `portcon->port_high` is a `uint32_t` printed with `%d`. That signed/unsigned mismatch is the same on every platform, because `uint32_t` is always unsigned. Main reported it as a warning. The PR replaces it with a 'portability' message. The 'uint32_t {aka unsigned int}' type name is nicer, but the severity is now wrong: this is not a platform-dependent issue. Portability checks are also off by default, so most users will no longer see this real finding. The PR's own TODO admits that the severity logic mishandles fixed-width types like `int32_t`. ---- 14 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libs/libsepol/libsepol_3.11.orig.tar.gz Result: main libsepol-3.11/cil/src/cil_policy.c:1978:3: warning: %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'. [invalidPrintfArgType_sint] Explanation: `pirqcon->pirq` is a `uint32_t`, and it is printed with `%d`. This is a real signedness mismatch on every platform, because `uint32_t` is always unsigned 32-bit. The warning is a true positive. The PR replaces this warning-severity report with a portability-severity one. The new text (`uint32_t {aka unsigned int}`) is a bit more informative. However, the downgrade to portability is wrong for a fixed-width type: the problem does not depend on the platform. Portability checks are also off by default, so users will usually stop seeing this true positive. The PR's own TODO admits this mishandles fixed-width types like int32_t. Overall the message became less accurate in severity and is effectively hidden. ---- 15 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libs/libsepol/libsepol_3.11.orig.tar.gz Result: main libsepol-3.11/cil/src/cil_write_ast.c:1464:3: warning: %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'. [invalidPrintfArgType_sint] Explanation: `ibpkeycon->pkey_low` and `pkey_high` are `uint32_t` and are printed with `%d`. That is a signedness mismatch on every platform: `uint32_t` is an unsigned type whether it is `unsigned int` or `unsigned long`. So this is a real bug, not a platform-dependent issue. Main reported it as a `warning`. With the PR the type gets an `originalTypeName` (`uint32_t`), so `getSeverity()` downgrades it to `portability`. Portability is not enabled by default, so most users lose this true positive. Showing `uint32_t {aka unsigned int}` is nicer, but the severity is now less accurate. The PR's own TODO admits that fixed-width types are handled wrongly here. ---- 16 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libs/libsepol/libsepol_3.11.orig.tar.gz Result: main libsepol-3.11/cil/src/cil_write_ast.c:1464:3: warning: %d in format string (no. 2) requires 'int' but the argument type is 'unsigned int'. [invalidPrintfArgType_sint] Explanation: `pkey_high` is a `uint32_t` passed to `%d`, so the sign-mismatch report is still valid. The PR does not drop it: the same diagnostic reappears as a 'your' line, now naming the real declared type ('uint32_t {aka unsigned int}') instead of only 'unsigned int'. That makes the message more accurate and easier to act on. The severity moves from warning to portability, which is reasonable because the underlying type of a typedef like `uint32_t` depends on the platform. The catch is that users who do not enable portability checks will no longer see this report. ---- 17 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libs/libsepol/libsepol_3.11.orig.tar.gz Result: main libsepol-3.11/cil/src/cil_write_ast.c:1489:4: warning: %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'. [invalidPrintfArgType_sint] Explanation: `portcon->port_low` and `port_high` are `uint32_t` values printed with `%d`. That is a signedness mismatch on every platform, because `uint32_t` is always unsigned, so the original severity `warning` was correct. The PR replaces this line with a `portability` message. The type name is now nicer ('uint32_t {aka unsigned int}'), but the issue is not platform-dependent, so the severity is less accurate. Portability checks are also off by default, so users lose this true positive unless they enable them. The PR's own TODO admits fixed-width types are handled wrongly here. ---- 18 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libs/libsepol/libsepol_3.11.orig.tar.gz Result: main libsepol-3.11/cil/src/cil_write_ast.c:1489:4: warning: %d in format string (no. 2) requires 'int' but the argument type is 'unsigned int'. [invalidPrintfArgType_sint] Explanation: portcon->port_high is a uint32_t printed with %d. That is a signedness mismatch on every platform, because uint32_t is always unsigned; it is not a portability concern. The PR replaces this 'warning' with a 'portability' message. The type name gets more precise ('uint32_t {aka unsigned int}'), but the severity is now wrong, and portability checks are off by default, so most users stop seeing this real mismatch. The PR's own TODO admits the severity logic is wrong for fixed-width types. ---- 19 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libs/libsepol/libsepol_3.11.orig.tar.gz Result: main libsepol-3.11/cil/src/cil_write_ast.c:1585:3: warning: %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'. [invalidPrintfArgType_sint] Explanation: pirqcon->pirq is a uint32_t that is printed with %d. The 'main' line is not truly removed. It is replaced by a 'your' line on the same location, which now names the type as 'uint32_t {aka unsigned int}' and reports it as portability. The signedness mismatch is still flagged, and the message is now more accurate because it shows the declared typedef. Reporting it as portability for a fixed-width typedef is debatable, since uint32_t vs int is really a signedness issue. The PR author marks this with a TODO. Overall the message is more informative, so the removal of the old line is acceptable. ---- 20 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libs/libsepol/libsepol_3.11.orig.tar.gz Result: main libsepol-3.11/cil/src/cil_write_ast.c:1608:4: warning: %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'. [invalidPrintfArgType_sint] Explanation: `ioportcon->ioport_low` is a `uint32_t` printed with `%d`. That is a signedness mismatch on every platform, because `uint32_t` is always unsigned. Main reported it as a warning, which is correct. The PR now fills `originalTypeName` for library typedefs, so `getSeverity` downgrades the finding to portability. The 'aka uint32_t' text is nicer, but calling it portability is wrong: the mismatch does not depend on the platform. Portability checks are also off by default, so most users lose this true positive. The PR's own TODO admits that fixed-width types like `int32_t` are handled badly by this logic. ---- 21 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libs/libsepol/libsepol_3.11.orig.tar.gz Result: main libsepol-3.11/cil/src/cil_write_ast.c:1610:4: warning: %d in format string (no. 2) requires 'int' but the argument type is 'unsigned int'. [invalidPrintfArgType_sint] Explanation: ioport_low and ioport_high are uint32_t, and they are printed with %d. That is a signedness mismatch on every platform, because uint32_t is always unsigned. Main reported it as a 'warning'. The PR replaces it with a 'portability' message, because the argument now carries an original type name (uint32_t). The new text is more descriptive, but the severity is now wrong: the problem does not depend on the platform. Portability checks are also often disabled, so users may no longer see this real issue. The PR's own TODO admits that fixed-width types are handled wrongly here. ---- 22 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libs/libsepol/libsepol_3.11.orig.tar.gz Result: your libsepol-3.11/cil/src/cil_policy.c:1840:3: portability: %d in format string (no. 1) requires 'int' but the argument type is 'uint32_t {aka unsigned int}'. [invalidPrintfArgType_sint] Explanation: `ibpkeycon->pkey_low` is a `uint32_t` printed with `%d`. That is a signedness mismatch on every platform, because `uint32_t` is always unsigned; it does not depend on the platform. Main reported it as a warning. With the PR, the type now carries `originalTypeName` "uint32_t", so `getSeverity()` downgrades it to portability. The text naming `uint32_t` is slightly nicer, but the finding is now hidden unless portability checks are enabled. The PR itself admits this is wrong for fixed-width types in its TODO, and had to enable portability in the test to keep these findings. This is a mis-categorisation that hides a true positive by default. ---- 23 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libs/libsepol/libsepol_3.11.orig.tar.gz Result: your libsepol-3.11/cil/src/cil_policy.c:1884:4: portability: %d in format string (no. 1) requires 'int' but the argument type is 'uint32_t {aka unsigned int}'. [invalidPrintfArgType_sint] Explanation: `portcon->port_low` and `port_high` are `uint32_t` and are printed with `%d`, which is a real signed/unsigned format mismatch. Main reported it as a warning. The PR now sets `originalTypeName` for library pod types, so the finding is downgraded to portability severity. The type text (`uint32_t {aka unsigned int}`) is clearer, but the severity is less accurate: `uint32_t` is unsigned on every platform, so this is not platform-dependent. Users who enable warnings but not portability will no longer see the bug. The PR's own TODO admits that fixed-width types like `int32_t` are handled wrongly. ---- 24 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libs/libsepol/libsepol_3.11.orig.tar.gz Result: your libsepol-3.11/cil/src/cil_policy.c:1884:4: portability: %d in format string (no. 2) requires 'int' but the argument type is 'uint32_t {aka unsigned int}'. [invalidPrintfArgType_sint] Explanation: `portcon->port_high` is a `uint32_t` printed with `%d`. That is a signedness mismatch on every platform, because `uint32_t` is always unsigned. Main reported it as a warning. The PR now sets `originalTypeName` for library types, so `getSeverity` downgrades it to portability. This finding is not platform-dependent, so 'portability' is the wrong category. Portability checks are off by default, so most users would no longer see this true positive. The PR's own TODO admits fixed-width types are mishandled. The added 'uint32_t {aka unsigned int}' text is nicer, but the severity change makes the diagnostic less accurate and hides it by default. ---- 25 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libs/libsepol/libsepol_3.11.orig.tar.gz Result: your libsepol-3.11/cil/src/cil_policy.c:1978:3: portability: %d in format string (no. 1) requires 'int' but the argument type is 'uint32_t {aka unsigned int}'. [invalidPrintfArgType_sint] Explanation: `pirqcon->pirq` is a `uint32_t` printed with `%d`. That is a signedness mismatch on every platform, because `uint32_t` is always unsigned. Main reported it as a warning. The PR now gives the library type an `originalName`, so `getSeverity` downgrades it to portability. The new text 'uint32_t {aka unsigned int}' is more informative. But the problem is not a portability issue, and portability checks are off by default, so most users will no longer see this real finding. The PR's own TODO admits this severity logic is wrong for fixed-width types like `int32_t`/`uint32_t`. ---- 26 / 50 ---- Verdict: REGRESSION (low confidence) Package: https://ftp.debian.org/debian/pool/main/libs/libsepol/libsepol_3.11.orig.tar.gz Result: your libsepol-3.11/cil/src/cil_write_ast.c:1464:3: portability: %d in format string (no. 2) requires 'int' but the argument type is 'uint32_t {aka unsigned int}'. [invalidPrintfArgType_sint] Explanation: `ibpkeycon->pkey_low` and `pkey_high` are `uint32_t` but are printed with `%d`. That is a signed/unsigned mismatch on every platform, so it is a real (if usually harmless) finding and not a portability issue. The PR keeps the same finding but drops its severity from warning to portability, presumably because the argument is now a library typedef. The new type text 'uint32_t {aka unsigned int}' is more informative. However, the severity is now less accurate, and users running only `--enable=warning` stop seeing the issue. The PR's own TODO admits fixed-width types like `int32_t` are handled poorly here. Whether the downgrade is acceptable is debatable, so confidence is low. ---- 27 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libs/libsepol/libsepol_3.11.orig.tar.gz Result: your libsepol-3.11/cil/src/cil_write_ast.c:1487:4: portability: %d in format string (no. 1) requires 'int' but the argument type is 'uint32_t {aka unsigned int}'. [invalidPrintfArgType_sint] Explanation: In libsepol, `portcon->port_low` is a `uint32_t`, and it is printed with `%d`. The finding is still valid: `uint32_t` is unsigned on every platform, so `%d` is a sign mismatch everywhere. The new text naming `uint32_t` is more informative. However, the PR now gives every library fixed-width type an originalTypeName, so `getSeverity()` lowers the severity from warning to portability. This is not a portability issue, since the mismatch is the same on all platforms. The PR's own TODO admits that fixed-width types like `int32_t` are mishandled. Users who enable warnings but not portability will no longer see this true positive, so the severity is now less accurate. ---- 28 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libs/libsepol/libsepol_3.11.orig.tar.gz Result: your libsepol-3.11/cil/src/cil_write_ast.c:1489:4: portability: %d in format string (no. 1) requires 'int' but the argument type is 'uint32_t {aka unsigned int}'. [invalidPrintfArgType_sint] Explanation: In libsepol, `portcon->port_low` and `port_high` are `uint32_t`, and they are printed with `%d`. The sign mismatch is real on every platform, because `uint32_t` is always unsigned. It is not a portability issue. The PR now sets the original type name for library fixed-width types, so `getSeverity()` downgrades this from warning to portability. The 'aka' text is nicer, but the severity is now wrong, and portability is off by default, so this valid finding would be hidden from most users. The PR's own TODO admits that fixed-width types like `int32_t` are handled wrongly here. ---- 29 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libs/libsepol/libsepol_3.11.orig.tar.gz Result: your libsepol-3.11/cil/src/cil_write_ast.c:1608:4: portability: %d in format string (no. 1) requires 'int' but the argument type is 'uint32_t {aka unsigned int}'. [invalidPrintfArgType_sint] Explanation: `ioportcon->ioport_low` is a `uint32_t` printed with `%d`, so this is a real signedness mismatch on every platform. `uint32_t` is always unsigned, so this is not a portability concern. Main reported it as a `warning`. The PR now sets `originalTypeName` for library types, which makes `getSeverity()` downgrade it to `portability`. That severity is wrong, and the check is disabled unless `--enable=portability` is given, so most users lose a true positive. The PR's own TODO admits this problem. The new type text (`uint32_t {aka unsigned int}`) is nicer, but the severity is less accurate. ---- 30 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libs/libsepol/libsepol_3.11.orig.tar.gz Result: your libsepol-3.11/cil/src/cil_write_ast.c:1610:4: portability: %d in format string (no. 1) requires 'int' but the argument type is 'uint32_t {aka unsigned int}'. [invalidPrintfArgType_sint] Explanation: `ioport_low` and `ioport_high` are `uint32_t` and are printed with `%d`. That is a signedness mismatch on every platform, because `uint32_t` is always unsigned. Main reported it as a `warning`. The PR only adds the `int32_t {aka signed int}`-style type name (here `uint32_t {aka unsigned int}`), which is a small textual improvement. As a side effect, `getSeverity()` now downgrades the finding to `portability`. That severity is wrong: the mismatch does not depend on the platform. The PR's own TODO admits fixed-width types are handled incorrectly. Since `portability` checks are often not enabled, this effectively hides a genuine (if minor) format-string bug. ---- 31 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/libs/libsepol/libsepol_3.11.orig.tar.gz Result: your libsepol-3.11/cil/src/cil_write_ast.c:1610:4: portability: %d in format string (no. 2) requires 'int' but the argument type is 'uint32_t {aka unsigned int}'. [invalidPrintfArgType_sint] Explanation: `ioportcon->ioport_high` is a `uint32_t` printed with `%d`. That is a signedness mismatch on every platform, so it is a real bug, not a portability issue. Main reported it as a warning. The PR now gives the typedef's original name (`uint32_t`), which makes `getSeverity` downgrade the finding to portability. Portability checks are disabled by default, so users effectively lose this true positive. The `aka uint32_t` text is nicer, but the severity is now wrong, as the PR's own TODO admits about fixed-width types. ---- 32 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/m/multimon-ng/multimon-ng_1.3.1+dfsg.orig.tar.gz Result: main multimon-ng-1.3.1+dfsg/demod_flex.c:1159:33: style: int result is assigned to long variable. If the variable is long to avoid loss of information, then you have loss of information. [truncLongCastAssignment] Explanation: Line 1159 computes `100 * flex->Demodulator.sample_freq` in int and then stores it in an `int64_t`. Choosing a 64-bit type suggests the author wants the extra range, but the multiplication can still overflow in int. That is exactly what truncLongCastAssignment is meant to flag, so the old warning was a valid style finding. The PR does not change this code or this check. Its side effect is that `int64_t` (a library typedef) now has a non-empty originalTypeName. The long-cast check most likely skips types whose originalTypeName is set, which would explain why the warning disappears here and in demod_flex_next.c. A true positive was lost unintentionally. ---- 33 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/m/multimon-ng/multimon-ng_1.3.1+dfsg.orig.tar.gz Result: main multimon-ng-1.3.1+dfsg/demod_flex.c:593:25: warning: %lld in format string (no. 13) requires 'long long' but the argument type is 'signed long'. [invalidPrintfArgType_sint] Explanation: `flex->Decode.capcode` is an `int64_t` printed with `%lld`. On this platform `int64_t` is `long`, so the mismatch is real but platform-dependent: on platforms where `int64_t` is `long long` it is correct. The correct fix is `PRId64`. The PR replaces the generic warning ('signed long') with a portability warning naming 'int64_t {aka signed long}'. That severity and text describe the issue more accurately, so the removal of the main line is part of a message improvement. ---- 34 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/m/multimon-ng/multimon-ng_1.3.1+dfsg.orig.tar.gz Result: main multimon-ng-1.3.1+dfsg/demod_flex.c:605:38: warning: %lld in format string (no. 1) requires 'long long' but the argument type is 'signed long'. [invalidPrintfArgType_sint] Explanation: `GroupCodes` is declared `int64_t`, which is `long` on this LP64 platform, and it is printed with `%lld`. That is not undefined behaviour on this platform, since `long` and `long long` are the same size here. It is a real portability mismatch, though: the portable way is `PRId64`. The PR replaces this generic warning with a portability message that names the actual type, `int64_t {aka signed long}`. The severity and the text are both more accurate. ---- 35 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/m/multimon-ng/multimon-ng_1.3.1+dfsg.orig.tar.gz Result: main multimon-ng-1.3.1+dfsg/demod_flex_next.c:1203:33: style: int result is assigned to long variable. If the variable is long to avoid loss of information, then you have loss of information. [truncLongCastAssignment] Explanation: Line 1203 computes `100 * flex->Demodulator.sample_freq` in (unsigned) int arithmetic and then stores it in an `int64_t`. That is exactly the pattern truncLongCastAssignment targets: the 64-bit destination suggests the author wants to avoid overflow, but the multiplication is done in 32 bits first. The warning was valid. It vanished only because the PR now sets originalTypeName for library types like int64_t, and the check skips types that have an originalTypeName. That is an unintended side effect; int64_t is always 64-bit, so the warning applies on every platform. With realistic sample rates the overflow is unlikely, but a true positive was lost. ---- 36 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/m/multimon-ng/multimon-ng_1.3.1+dfsg.orig.tar.gz Result: your multimon-ng-1.3.1+dfsg/demod_flex.c:593:25: portability: %lld in format string (no. 13) requires 'long long' but the argument type is 'int64_t {aka signed long}'. [invalidPrintfArgType_sint] Explanation: `flex->Decode.capcode` is declared as `int64_t` and is printed with `%lld`. On LP64 targets `int64_t` is `long`, so this is a real type mismatch. However, `long` and `long long` have the same size there, so it only matters for portability; the portable fix is `PRId64`. The new message names the actual declared type (`int64_t {aka signed long}`) and uses portability severity, which describes the problem more accurately than the old generic 'signed long' warning. ---- 37 / 50 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/m/multimon-ng/multimon-ng_1.3.1+dfsg.orig.tar.gz Result: your multimon-ng-1.3.1+dfsg/demod_flex.c:605:38: portability: %lld in format string (no. 1) requires 'long long' but the argument type is 'int64_t {aka signed long}'. [invalidPrintfArgType_sint] Explanation: `flex->GroupHandler.GroupCodes[groupbit][g]` is declared `int64_t`, and line 605 prints it with `%lld`. On LP64 Linux `int64_t` is `long`, so strictly the type does not match `long long`. On platforms where `int64_t` is `long long` it does match. That makes this a portability issue (the fix is `PRId64`), not a general type-mismatch warning. The new message names the real type `int64_t {aka signed long}` and uses portability severity, so it is more accurate than main's warning about 'signed long'. ---- 38 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/p/python-pyahocorasick/python-pyahocorasick_1.4.1.orig.tar.gz Result: your python-pyahocorasick_1.4.1.orig/trienode.c:193:13: portability: %d in format string (no. 1) requires 'int' but the argument type is 'uint32_t {aka unsigned int}'. [invalidPrintfArgType_sint] Explanation: `node->n` is a `uint32_t` and is printed with `%d`. That is a signedness mismatch on every platform, because `uint32_t` is always unsigned. Main reported it as a warning. The PR now reports it as portability only because the type has a typedef name. The added 'uint32_t {aka unsigned int}' text is nicer, but the severity is now wrong: this is not a platform-dependent issue. Portability checks are also off by default, so users would no longer see this valid finding. The PR's own TODO admits fixed-width types are mishandled by this severity logic. ---- 39 / 50 ---- Verdict: IMPROVEMENT (low confidence) Package: https://ftp.debian.org/debian/pool/main/r/reiser4progs/reiser4progs_1.2.2.orig.tar.gz Result: main reiser4progs-1.2.2/plugin/alloc/alloc40/alloc40.c:546:7: style: int result is assigned to long variable. If the variable is long to avoid loss of information, then you have loss of information. [truncLongCastAssignment] Explanation: Line 546 computes `size = (alloc->blksize - CRC_SIZE) * 8;`, where `size` is `uint64_t`. `blksize` is a filesystem block size (a few KB), so the 32-bit product cannot overflow in practice. The truncLongCastAssignment report is a pattern-based style warning with no real risk here. After the PR, `uint64_t` keeps its original typedef name, and the warning goes away (both hits in this package vanish). This looks like a side effect of the PR rather than a deliberate fix. Still, losing this noisy, non-actionable warning is slightly positive for users, though the check could argue the pattern is technically present. ---- 40 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/v/vdr-plugin-streamdev/vdr-plugin-streamdev_0.6.5.orig.tar.gz Result: main vdr-plugin-streamdev-0.6.5/libdvbmpeg/remux.c:541:9: warning: %d in format string (no. 2) requires 'int' but the argument type is 'unsigned int'. [invalidPrintfArgType_sint] Explanation: Line 541 passes vi->horizontal_size and vi->vertical_size, which are uint32_t fields, to fprintf with %d. This is a signedness mismatch. The values are only 12-bit sizes, so it is harmless in practice. Main reported it as a warning with the type 'unsigned int'. The PR reports the same finding with the declared type 'uint32_t {aka unsigned int}', which is more informative. It also tags it as portability, matching how Cppcheck already treats other typedef'd types such as size_t. The finding itself is kept, so this removed line is just the old wording. One caveat: portability is not enabled by default, and for uint32_t the mismatch is about sign rather than platform. Even so, the message is more accurate overall. ---- 41 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/v/vdr-plugin-streamdev/vdr-plugin-streamdev_0.6.5.orig.tar.gz Result: main vdr-plugin-streamdev-0.6.5/libdvbmpeg/remux.c:644:3: warning: %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'. [invalidPrintfArgType_sint] Explanation: `ai->bit_rate` is `uint32_t`, so `ai->bit_rate/1000` is `unsigned int` printed with `%d`. That signedness mismatch is the same on every platform, because `uint32_t` is always unsigned. Main reported it at warning severity, which was appropriate. The PR now attaches the typedef name, so `getSeverity` downgrades the finding to portability. That label is wrong: this is not a platform-dependent size issue. Portability checks are also off by default, so most users lose the warning. The PR's own TODO admits fixed-width types are handled badly. The 'uint32_t {aka unsigned int}' text is nicer, but losing a default-visible true positive outweighs that. ---- 42 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/v/vdr-plugin-streamdev/vdr-plugin-streamdev_0.6.5.orig.tar.gz Result: main vdr-plugin-streamdev-0.6.5/libdvbmpeg/remux.c:894:2: warning: %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'. [invalidPrintfArgType_sint] Explanation: `rem.time_off` is a `uint32_t` printed with `%d`. That is a signedness mismatch on every platform, because `uint32_t` is always unsigned. Main reported it as a warning. With the PR, `uint32_t` gets an `originalTypeName`, so `getSeverity()` downgrades the finding to portability. Portability is off by default, so most users no longer see a real, platform-independent mismatch. The new text naming `uint32_t` is nicer, but the severity is now wrong: this is not a portability issue. The PR itself adds a TODO admitting that fixed-width types are handled badly here. ---- 43 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/v/vdr-plugin-streamdev/vdr-plugin-streamdev_0.6.5.orig.tar.gz Result: main vdr-plugin-streamdev-0.6.5/libdvbmpeg/transform.c:1861:4: warning: %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'. [invalidPrintfArgType_sint] Explanation: `ai->bit_rate` is a `uint32_t` (unsigned), and `ai->bit_rate/1000` is passed to `%d`. That is a signedness mismatch on every platform. The removed warning was correct. The PR does not drop the finding but replaces it with the same message tagged `portability` instead of `warning`. Naming `uint32_t` in the message is a small gain. However, a fixed-width unsigned type passed to `%d` is not platform-dependent, so the portability label is wrong. Portability is also off by default, so most users will no longer see this real mismatch. The PR's own TODO says fixed-width types are now handled incorrectly. Overall this makes the finding less accurate and less visible. ---- 44 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/v/vdr-plugin-streamdev/vdr-plugin-streamdev_0.6.5.orig.tar.gz Result: main vdr-plugin-streamdev-0.6.5/libdvbmpeg/transform.c:1922:10: warning: %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'. [invalidPrintfArgType_sint] Explanation: `ai->bit_rate` is a `uint32_t` printed with `%d`. The main-only line is not a lost finding: the PR reports the same issue as portability, with the more accurate type text `'uint32_t {aka unsigned int}'`. The mismatch is real, but here it is mostly a portability concern. The value (`bit_rate/1000`) is small and fits in `int`, so the signedness difference is harmless in practice. `uint32_t` may be `unsigned long` on some platforms, which would make `%d` a genuine size mismatch. Naming the typedef and classifying it as portability, as Cppcheck already does for other typedefs, makes the diagnostic more precise. The downside is that it is hidden unless portability checks are enabled. ---- 45 / 50 ---- Verdict: IMPROVEMENT (medium confidence) Package: https://ftp.debian.org/debian/pool/main/v/vdr-plugin-streamdev/vdr-plugin-streamdev_0.6.5.orig.tar.gz Result: main vdr-plugin-streamdev-0.6.5/libdvbmpeg/transform.c:1926:10: warning: %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'. [invalidPrintfArgType_sint] Explanation: `ai->frequency` is declared as `uint32_t`. The PR now records `uint32_t` as the original type name. The same diagnostic is therefore still reported, now as a portability issue naming 'uint32_t {aka unsigned int}'. That message is more accurate. Portability is also a fitting severity: the correct way to print a `uint32_t` portably is PRIu32, since `uint32_t` maps to different base types on different platforms. The value here is a small frequency, so the sign mismatch is harmless and a generic warning was overstated. The main-only line goes away only because its text and severity changed, not because a true positive was lost. ---- 46 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/v/vdr-plugin-streamdev/vdr-plugin-streamdev_0.6.5.orig.tar.gz Result: your vdr-plugin-streamdev-0.6.5/libdvbmpeg/remux.c:541:9: portability: %d in format string (no. 1) requires 'int' but the argument type is 'uint32_t {aka unsigned int}'. [invalidPrintfArgType_sint] Explanation: At line 541, `vi->horizontal_size` and `vi->vertical_size` are `uint32_t` and are printed with `%d`. That signedness mismatch is wrong on every platform, because `uint32_t` is always unsigned. Main reported it as a warning. The PR now reports it as portability, since `uint32_t` gets an originalTypeName. Portability checks are off by default, so most users stop seeing this true positive, and calling a signedness mismatch a portability issue is inaccurate. The PR's own TODO admits fixed-width types are handled wrongly here. The added 'uint32_t {aka unsigned int}' text is nicer, but losing the default-visible warning outweighs it. ---- 47 / 50 ---- Verdict: REGRESSION (low confidence) Package: https://ftp.debian.org/debian/pool/main/v/vdr-plugin-streamdev/vdr-plugin-streamdev_0.6.5.orig.tar.gz Result: your vdr-plugin-streamdev-0.6.5/libdvbmpeg/remux.c:644:3: portability: %d in format string (no. 1) requires 'int' but the argument type is 'uint32_t {aka unsigned int}'. [invalidPrintfArgType_sint] Explanation: At line 644, `ai->bit_rate/1000` (a `uint32_t` value) is printed with `%d`. That is a signed/unsigned mismatch on every platform, because `uint32_t` is always unsigned. Main reported it as a warning. The PR now gives it portability severity only because the type token has an original typedef name. The text is more informative ('uint32_t {aka unsigned int}'), but downgrading a platform-independent sign mismatch to portability is less accurate. It also hides the finding unless portability checks are enabled. The PR's own TODO admits the severity logic is wrong for fixed-width types. ---- 48 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/v/vdr-plugin-streamdev/vdr-plugin-streamdev_0.6.5.orig.tar.gz Result: your vdr-plugin-streamdev-0.6.5/libdvbmpeg/remux.c:894:2: portability: %d in format string (no. 1) requires 'int' but the argument type is 'uint32_t {aka unsigned int}'. [invalidPrintfArgType_sint] Explanation: `rem.time_off` is a `uint32_t` and is printed with `%d`, so the signed/unsigned mismatch is real on every platform. The old warning (severity `warning`, type 'unsigned int') was a correct true positive. The new message is more informative because it names the `uint32_t` typedef. However, the PR now gives every library typedef an `originalTypeName`, which makes `getSeverity` downgrade the finding to `portability`. A fixed-width `uint32_t` vs `%d` sign mismatch is not platform-dependent, so `portability` is the wrong category. The PR's own TODO admits this is a problem for fixed-width types. Users running with `--enable=warning` but without portability checks would lose this valid diagnostic, so overall the change is a regression. ---- 49 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/v/vdr-plugin-streamdev/vdr-plugin-streamdev_0.6.5.orig.tar.gz Result: your vdr-plugin-streamdev-0.6.5/libdvbmpeg/transform.c:1758:3: portability: %d in format string (no. 1) requires 'int' but the argument type is 'uint32_t {aka unsigned int}'. [invalidPrintfArgType_sint] Explanation: `vi->horizontal_size` and `vi->vertical_size` are `uint32_t`, and they are printed with `%d`. That is a signedness mismatch on every platform, because `uint32_t` is always unsigned. So the problem does not depend on the platform. Main reported it as a warning. The PR only made the type name nicer (`uint32_t {aka unsigned int}`). It also reclassified the finding as 'portability', because the fixed-width typedef now carries an originalTypeName. That severity is wrong, and the PR's own TODO admits fixed-width types are handled poorly. Users who don't enable portability checks will no longer see this true positive. The message text is slightly better, but the misleading and less visible severity outweighs that. ---- 50 / 50 ---- Verdict: REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/v/vdr-plugin-streamdev/vdr-plugin-streamdev_0.6.5.orig.tar.gz Result: your vdr-plugin-streamdev-0.6.5/libdvbmpeg/transform.c:1922:10: portability: %d in format string (no. 1) requires 'int' but the argument type is 'uint32_t {aka unsigned int}'. [invalidPrintfArgType_sint] Explanation: `ai->bit_rate/1000` is unsigned (a `uint32_t` divided by an int), so printing it with `%d` is a signedness mismatch. `uint32_t` is unsigned on every platform, so this is a plain bug, not a portability issue. The PR only adds the original typedef name, which makes `getSeverity` downgrade the same true positive from warning to portability. The 'aka uint32_t' text is slightly more informative, but portability checks are off by default, so most users will no longer see this finding. The PR's own TODO admits that fixed-width types are handled wrongly here.