Using a Fedora 33 with a not so recent cppcheck, and based on commit hash 37fac7
$ cppcheck --version
Cppcheck 2.3
$ cppcheck --force --xml-version=2 --enable=warning -I/usr/include ./backend 2>cppcheck.xml
(needs approximately 3 hours)
$ cat cppcheck.xml | grep -A3 -ie "arrayindexoutofbounds" > todo-out-of-bounds.txt
The todo file contains 7 issues.
The todo file doesn't contain the recent reported issue in code1.c.
So would have been supposedly not be found with cppcheck 2.3
I missed the following one due to a different warning type
Hi, I think commit [4d3aae] probably addresses most of these.
There was one definite bug found, in "testcommon.c", where it was using
sizeof()
instead ofARRAY_SIZE()
.The AZTEC warning was a nicety (only need to check not zero instead of
>= 2
) but good to fix.The QR warnings I'd consider dubious - was using non-contiguous version indexes for RMQR and MICROQR (which doesn't matter) - but changed them anyway to be contiguous. Likewise the "test_gb18030" comparison was redundant (but sometimes redundancy is ok) - but commented it out anyway.
Unfortunately I found running "cppcheck" - tried various versions, 2.5, 2.4, 2.3 - so slow as to be close to unusable. Only ran it on the individual files in your report, and gave up trying to run it on "testcommon.c", it was taking so long (and crucifying my machine).
Thanks, Martin
Related
Commit: [4d3aae]
I have checked again (without the --force parameter)
now the following two warnings don't look that nice in the cppcheck output
I suppressed the codablock with commit [7cd0d9].
Tried a few things to suppress the code128 one but it looks like a false positive to me, e.g. changing the test to
source > 127 + 32
gives the warning thatC128Table[107] accessed at index 127, which is out of bounds
, which given that source is< 256
isn't possible.Edit: oh I missed that changes the line to 244, so it is possible. Sticking a
source <= 127
around that fixes that but don't think this is adding anything to the source...Related
Commit: [7cd0d9]
Last edit: Git Lost 2021-07-06
Hi, after sleeping on it commit [f03da2] suppresses the code128 warning, plus some others.
Running cppcheck without
--force
makes a big difference time-wise, though still very CPU intensive.Related
Commit: [f03da2]
So what happens if we have 0 <= source <= 31, this would give source-32 <= 31 - 32 = -1
and the array index again is negative. There might be something missing here.
source
is never < 32 and never > 127 and < 127 + 32 for Set B, which is why the warning is somewhat dubious and the suppression a bit OTT.This might be true, but a static analysis tool might not get that.
So why not introduce for each interval a separate if-else-branch,
and mark the unreachable ones as already done?
Perhaps one could use some early returns here in order to remove some if-else clutter.
Well the unreachable ones aren't already done, if I get your meaning, they would be an internal programming error, and the callers of
c128_set_b()
should really check the return value and crap out if false, which I didn't bother to do here (but may do in the future), but MRs for code style improvements are always welcome!Your're welcome :-)
Regarding the suggestion for a MR.
I still don't get the middle branch?
So let's try it here. Would that work?
I hope I understood your condition correctly.
This would now be a no-brainer for me
because I can easily see now the nonnegativity of the array indices used.
Regards Andre
Last edit: Andre Maute 2021-07-07
Patch applied [e1f22e], much nicer!
Related
Commit: [e1f22e]
Thank you Martin for the fixes.
This Ticket can be closed now.