Bug 2240705 - False positive knownConditionTrueFalse with cppcheck 2.12.0
Summary: False positive knownConditionTrueFalse with cppcheck 2.12.0
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: cppcheck
Version: 38
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Susi Lehtola
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-09-26 01:06 UTC by David Gibson
Modified: 2024-06-03 00:46 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2024-05-31 08:34:42 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description David Gibson 2023-09-26 01:06:32 UTC
New cppcheck version has introduced a false positive knownConditionTrueFalse case where it incorrectly deduces that a MIN() operation is clamping a value to 0.

Problem seems to be specific to unsigned variables.

Reproducible: Always

Steps to Reproduce:
1. Create this C file, example.c

#ifndef MIN
#define MIN(x, y)		(((x) < (y)) ? (x) : (y))
#endif

void example(unsigned int old_val)
{
	unsigned int new_val = MIN(old_val, 65535);

	if (!new_val) {
	}
}

2. Run
    $ cppcheck --enable=all example.c

Actual Results:  
$ cppcheck --enable=all example.c 
Checking example.c ...
example.c:9:6: style: Condition '!new_val' is always true [knownConditionTrueFalse]
 if (!new_val) {
     ^
example.c:7:25: note: Assignment 'new_val=((old_val)<65535)?old_val:65535', assigned value is less than 1
 unsigned int new_val = MIN(old_val, 65535);
                        ^
example.c:9:6: note: Condition '!new_val' is always true
 if (!new_val) {
     ^
example.c:5:0: style: The function 'example' is never used. [unusedFunction]
void example(unsigned int old_val)
^
Active checkers: 106/565


Expected Results:  
Only the unusedFunction warning.  The knownConditionTrueFalse warning is clearly bogus.

Occurs with both the current Fedora 38 released cppcheck:
    $ cppcheck --version
    Cppcheck 2.12.0
    $ rpm -q cppcheck
    cppcheck-2.12.0-2.fc38.x86_64

Also occurs with the update in testing:
    $ cppcheck --version
    Cppcheck 2.12.1
    $ rpm -q cppcheck
    cppcheck-2.12.1-1.fc38.x86_64

Problem does *not* occur with the version in Fedora 38 base (not updates):
    $ cppcheck --version
    Cppcheck 2.9
    $ rpm -q cppcheck
    cppcheck-2.9-4.fc38.x86_64

Comment 1 David Gibson 2023-09-29 05:35:00 UTC
I also mentioned this on the upstream forums at:

https://sourceforge.net/p/cppcheck/discussion/general/thread/f5b1a00646/

The problem still appears to be there in the latest upstream git.

Comment 2 Aoife Moloney 2024-05-31 08:34:42 UTC
Fedora Linux 38 entered end-of-life (EOL) status on 2024-05-21.

Fedora Linux 38 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 3 David Gibson 2024-06-03 00:46:18 UTC
Although I can't see any updates on the upstream trackers indicating this is fixed, it does seem to have gone away in cppcheck-2.13.0-3.fc40.x86_64 (Fedora 40).


Note You need to log in before you can comment on or make changes to this bug.