Fix #15000 (CheckCondition: detect compareValueOutOfTypeRange for bounded cast/arithmetic expressions) by jfdeverge · Pull Request #8819 · cppcheck-opensource/cppcheck

jfdeverge · 2026-08-31T15:31:47Z

There was missing detection of 'MISRA C:2012 Rule 14.3" on some specific code structure generated by Matlab Simulink coder.
We identified these issues by comparing its results with reports previously generated by our company’s internal tool on the same software.

The bug report would have looked like below.

Problem

Cppcheck did not report a MISRA C:2012 Rule 14.3 violation when a comparison
used an integer expression whose range was provably bounded by casts and
constant arithmetic. The existing check handled a variable compared with a
value outside the variable's declared type range, but did not evaluate this
equivalent expression form.

Minimal Reproducer

typedef unsigned int uint32;
typedef unsigned long long uint64;
typedef long long sint64;

void f(uint32 x)
{
    uint64 tmp = ((uint64)x) + 1ULL;
    if (tmp > 4294967295ULL)
        tmp = 4294967295ULL;

    if ((((sint64)((uint32)tmp)) - 1LL) > 4294967295LL) {
    }
}

After the clamp and casts, the left-hand expression cannot exceed
UINT32_MAX - 1. Therefore the final condition is always false and should
produce the compareValueOutOfTypeRangeError diagnostic, which the MISRA
postprocessor maps to Rule 14.3.

Observed Behavior

Before the fix, the final comparison produced no diagnostic. This allowed the
generated-code pattern to pass through the cppcheck-based MISRA pipeline
without the expected Rule 14.3 finding.

Fix

The condition checker now:

calculates ranges for supported scalar integer types;
recursively evaluates integer casts, transparent parentheses, and addition
or subtraction by constant expressions;
evaluates comparisons against the resulting interval when the result is
provably always true or always false; and
retains the existing compareValueOutOfTypeRangeError diagnostic path.

Uncertain or unsupported ranges remain unreported to avoid speculative
findings. Interval arithmetic includes overflow guards.

Regression Coverage

The exact typedef-based reproducer is covered by
TestCondition::compareOutOfTypeRange in test/testcondition.cpp. The focused
test, the complete TestCondition suite, and the registered CTest target pass
with the fix.

chrchr-github · 2026-09-01T08:46:38Z

+              "    if ((((sint64)((uint32)tmp)) - 1LL) < 0LL) {}\n"
+              "    if ((((sint64)((uint32)tmp)) - 1LL) > 4294967295LL) {}\n"
+              "}\n", settingsUnix64);
+        ASSERT_EQUALS("[test.cpp:9:43]: (style) Comparing expression of type 'signed long long' against value 4294967295. Condition is always false. [compareValueOutOfTypeRangeError]\n",


The text/ID of the warning seems incorrect. 4294967295 is within range for signed long long.

Hello! The condition is essentially (sint64), the diagnostic log is correct. But the check is only possible because there is a (uint32) inside.

hmm it will at least be confusing. At first glance it sounds like 'signed long long' expressions shouldn't be compared against 4294967295.

It might be less confusing if the type 'signed long long' would be removed. The range of 'signed long long' expressions is much greater, the issue here is that the expression range corresponds to a 'uint32'. How problematic would that be to remove the type if the expression range does match the type range?

chrchr-github · 2026-09-01T09:36:41Z

I have created this ticket: https://trac.cppcheck.net/ticket/15000

jfdeverge · 2026-09-01T12:25:17Z

I will update the commit message with Fix #15000 ...

aadanen · 2026-09-01T20:29:31Z

+        return false;
+
+    std::uint8_t bits = 0;
+    switch (tok->valueType()->type) {


maybe this switch could be simplified to something like

if (tok->valueType()->isIntegral()) bits = settings.platform.char_bit * tok->valueType()->getSizeOf(settings, ValueType::Accuracy::ExactOrZero, ValueType::SizeOf::Pointee);

I think it would be shorter, duplicate less logic, and it would also support wchar_t

the check for isIntegral() could even be moved up to line 1980 to be very clear that this function only works for integral types

Cheers!
--Aaron

Thanks for pointing to getSizeOf, it simplifies a lot.

aadanen · 2026-09-01T20:53:28Z

+            lower = -(MathLib::bigint(1) << (bits - 1));
+            upper = max / 2;
+        }
+    } else {


enum Sign : std::uint8_t { UNKNOWN_SIGN, SIGNED, UNSIGNED } sign = UNKNOWN_SIGN;

I think if the sign is unknown you should probably return false, not treat it the same as an UNSIGNED

…ded cast/arithmetic expressions

danmar · 2026-09-06T11:14:01Z

The PR title should be updated. The commit message will not be shown in the git log but the PR title will.

jfdeverge · 2026-09-06T11:28:00Z

The PR title should be updated. The commit message will not be shown in the git log but the PR title will.

Done.

PR title updated to "Fix #15000 CheckCondition: detect compareValueOutOfTypeRange for bounded cast/arithmetic expressions" ; let me know if better convention would apply here.

danmar · 2026-09-06T16:25:08Z

+    if (tok->isCast() && tok->astOperand1()) {
+        MathLib::bigint typeLower;
+        MathLib::bigint typeUpper;
+        const bool hasSourceRange = getIntegerExpressionRange(tok->astOperand1(), settings, lower, upper);


c++ casts have two operands.

danmar · 2026-09-06T16:27:28Z

+        return lower <= upper;
+    }
+
+    if (Token::simpleMatch(tok, "(") && tok->astOperand1())


I am not sure what exact code you target here.

danmar · 2026-09-06T16:28:23Z

+        MathLib::bigint constantLower;
+        MathLib::bigint constantUpper;
+        if (!getIntegerExpressionRange(tok->astOperand1(), settings, operandLower, operandUpper) ||
+            !getIntegerExpressionRange(tok->astOperand2(), settings, constantLower, constantUpper) ||


we will always return false for a unary +|- ?

danmar · 2026-09-06T16:33:45Z

+              "    if ((((sint64)((uint32)tmp)) - 1LL) < 0LL) {}\n"
+              "    if ((((sint64)((uint32)tmp)) - 1LL) > 4294967295LL) {}\n"
+              "}\n", settingsUnix64);
+        ASSERT_EQUALS("[test.cpp:9:43]: (style) Comparing expression of type 'signed long long' against value 4294967295. Condition is always false. [compareValueOutOfTypeRangeError]\n",


hmm it will at least be confusing. At first glance it sounds like 'signed long long' expressions shouldn't be compared against 4294967295.

It might be less confusing if the type 'signed long long' would be removed. The range of 'signed long long' expressions is much greater, the issue here is that the expression range corresponds to a 'uint32'. How problematic would that be to remove the type if the expression range does match the type range?

danmar · 2026-09-06T16:51:56Z

The PR title should be updated. The commit message will not be shown in the git log but the PR title will.

Done.

PR title updated to "Fix #15000 CheckCondition: detect compareValueOutOfTypeRange for bounded cast/arithmetic expressions" ; let me know if better convention would apply here.

Thanks! I don't have a strict pattern that must be followed but I typically put parentheses around the ticket title. Most important is that you indicated which ticket it solves..

danmar · 2026-09-06T16:56:37Z

        Certainty::normal);
 }

+static bool getIntegerTypeRange(const Token* tok,


I have the feeling we have a utility function to determine min/max values of an integer type.

danmar · 2026-09-06T16:57:33Z

+    return true;
+}
+
+static bool getIntegerExpressionRange(const Token* tok,


have you checked if there is some similar utility function somewhere?

danmar · 2026-09-06T16:58:28Z

+}
+
+static bool getIntegerExpressionRange(const Token* tok,
+                                      const Settings& settings,


I don't have a strong opinion but passing settings is overkill we could just pass a platform.

danmar · 2026-09-06T17:03:12Z

+{
+    if (!tok)
+        return false;
+    if (tok->hasKnownIntValue()) {


if there is not a known value.. I think it would be good to consider the "impossible" values.
Example:

void foo(uint32_t x) { if (x > 100) return; a = (uint64_t)x; }

In the cast the values for token x are (this is the --debug output):

x {!<=-1,!>=101,<=100}

The !>=101 means x cannot have values 101 and more.

chrchr-github · 2026-09-06T18:41:27Z

I have a feeling that some of the logic should be performed in ValueFlow and not in the check. Currently, ValueFlow only seems to handle bool value ranges. @danmar What do you think?

jfdeverge force-pushed the dev/fix_misra_14_3 branch from a1c4a25 to 8dc01be Compare August 31, 2026 15:33

github-advanced-security Bot found potential problems Aug 31, 2026

View reviewed changes

Comment thread lib/checkcondition.cpp Fixed

jfdeverge force-pushed the dev/fix_misra_14_3 branch from 8dc01be to d37f6b1 Compare August 31, 2026 16:02

chrchr-github reviewed Sep 1, 2026

View reviewed changes

jfdeverge force-pushed the dev/fix_misra_14_3 branch from d37f6b1 to 3e3fa63 Compare September 1, 2026 12:26

aadanen reviewed Sep 1, 2026

View reviewed changes

Fix #15000 CheckCondition: detect compareValueOutOfTypeRange for boun…

2d5f3a7

…ded cast/arithmetic expressions

jfdeverge force-pushed the dev/fix_misra_14_3 branch from 3e3fa63 to 2d5f3a7 Compare September 2, 2026 09:40

jfdeverge changed the title ~~Fix Rule 14.3 detection for bounded expressions~~ Fix #15000 CheckCondition: detect compareValueOutOfTypeRange for bounded cast/arithmetic expressions Sep 6, 2026

danmar reviewed Sep 6, 2026

View reviewed changes

danmar changed the title ~~Fix #15000 CheckCondition: detect compareValueOutOfTypeRange for bounded cast/arithmetic expressions~~ Fix #15000 (CheckCondition: detect compareValueOutOfTypeRange for bounded cast/arithmetic expressions) Sep 6, 2026

danmar reviewed Sep 6, 2026

View reviewed changes

Uh oh!

Conversation

jfdeverge commented Aug 31, 2026

Problem

Minimal Reproducer

Observed Behavior

Fix

Regression Coverage

Uh oh!

Uh oh!

chrchr-github Sep 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

chrchr-github commented Sep 1, 2026

Uh oh!

jfdeverge commented Sep 1, 2026

Uh oh!

aadanen Sep 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

danmar commented Sep 6, 2026

Uh oh!

jfdeverge commented Sep 6, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

danmar commented Sep 6, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

chrchr-github commented Sep 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

chrchr-github Sep 1, 2026 •

edited

Loading

aadanen Sep 1, 2026 •

edited

Loading