unmatchedSuppression possible regression in cppcheck-2.1

[David Keegan]

I have a c++ codebase with 156 in-source cppcheck-suppression. In cppcheck-1.9 these all work as expected, and no issues are emitted by ccpcheck. In cppcheck-2.1 I get "unmatchedSuppression" issues for 9 out of 156. If I remove the 9 suppression comments, I get the original issue that I want to suppress, for example: knownConditionTrueFalse, redundantAssignment, unusedFunction, ConfigurationNotChecked, noExplicitConstructor, unreadVariable. The original issues are all valid , and the code hasn't changed, so it seems to me it's a regression in cppcheck, and the unmatchedSuppressions are bogus. Is there a workaround for this?

[Daniel Marjamäki]

I noticed yesterday that we have problems with inline suppressions. I am not sure if your problem is related.

I made a partial fix for the problems I saw yesterday and I hope I can make a full fix soon.

If you can provide a small example code that would be very helpful. I suggest that you try to bisect the code: can you reproduce the problem for a "unreadVariable" if you remove all code exept the function? can you reproduce the problem if you remove some code in the function.
I don't think it's important if the cppcheck warning is correct in your example code, if it shows the problem then it's very interesting.

Or.. if you want you can compile/download latest cppcheck and see if we have solved the problem. Compiling from source code is pretty easy. There is a nightly windows release build: https://github.com/danmar/cppcheck/actions?query=workflow%3Arelease-windows you can download an installer or exe file from there.

[David Keegan]

Daniel,

Thanks for the quick response.

Yes, I'll try to come up with a small example, and will also try the latest code.

Regards,
David.

[David Keegan dksw.daithi@gmail.com 01 2988743 or 086 8777046]
[56 Roebuck Downs Dublin IRELAND D14 K6P7]

"Daniel Marjamäki" writes:

I noticed yesterday that we have problems with inline suppressions. I am not
sure if your problem is related.

I made a partial fix for the problems I saw yesterday and I hope I can make a
full fix soon.

If you can provide a small example code that would be very helpful. I suggest
that you try to bisect the code: can you reproduce the problem for a
"unreadVariable" if you remove all code exept the function? can you reproduce
the problem if you remove some code in the function.
I don't think it's important if the cppcheck warning is correct in your
example code, if it shows the problem then it's very interesting.

Or.. if you want you can compile/download latest cppcheck and see if we have
solved the problem. Compiling from source code is pretty easy. There is a
nightly windows release build:
https://github.com/danmar/cppcheck/actions?query=workflow%3Arelease-windows
you can download an installer or exe file from there.

---

unmatchedSuppression possible regression in cppcheck-2.1

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/cppcheck/discussion/general/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

--

[Daniel Marjamäki]

For information I made the "full fix" for the problems I have seen. So well if latest cppcheck doesn't solve your problems then a reduced example code would be really interesting.

[David Keegan]

Daniel,

The latest cppcheck doesn't resolve the problem, but here's a small example
that reproduces it:

Source:

namespace Misc
{ // cppcheck-suppress unusedFunction
int AsException()
{ int Rv = 1;
return Rv;
}
}

cppcheck options:
--std=c++20\
--template='{file}:{line}:0: {severity}: {message} [-W{id}]'\
--inline-suppr\
--platform=unix64\
--language=c++\
--enable=all\
--inconclusive\
--force\
--verbose\

cppcheck output:
Checking /home/davidk/Temp/t.cpp ...
Defines:
Undefines:
Includes:
Platform:unix64
/home/davidk/Temp/t.cpp:3:0: style: The function 'AsException' is never used. [-WunusedFunction]
/home/davidk/Temp/t.cpp:2:0: information: Unmatched suppression: unusedFunction [-WunmatchedSuppression]

Expected output: No error output because the unusedFunction
issue should be suppressed by the inline suppression.

The second error message shows the inline suppression is
being recognised as such, but it clearly it isn't being applied.

NOTE: If insert a newline between the first opening brace
and the suppression comment, it works as expected. The
suppression is applied and there is no error output.

However I shouldn't have to make this source change, and the
issue did not exist in cppcheck-2.0.

Regards,
David.

[Daniel Marjamäki]

hmm.. if you put a suppression comment directly after some code then cppcheck assumes that the suppression is for that code.

So you can fix the fp with either:

namespace Misc
{
int AsException() // cppcheck-suppress unusedFunction
{ int Rv = 1;
return Rv;
}
}

or:

namespace Misc
{
// cppcheck-suppress unusedFunction
int AsException()
{ int Rv = 1;
return Rv;
}
}

[Daniel Marjamäki]

Maybe you knew this already. Do you feel we should handle your suppression also or are you fine with my suggestions?

[David Keegan]

Maybe you knew this already. Do you feel we should handle your suppression also or are you >fine with my suggestions?

This all worked until I upgraded to cppcheck-2.1, so I'm reluctant to start making workaround changes.

[David Keegan]

I thought the suppression only applied to the following line. Your first workaround suggests otherwise. Can you please explain in a bit more detail how it decides on the target for the suppression? The first of your suggested workarounds might be workable, but it's a big codebase and I don't want to make changes without a full understanding of how the suppression is applied.

[Daniel Marjamäki]

Can you please read section 6.5 in the manual.. http://cppcheck.sourceforge.net/manual.pdf
Do you feel that we need to explain it better in the manual?

maybe it's not 100% clear how it works if there is code both on the same line and on the next line.. do you think that should be clarified?

[Daniel Marjamäki]

I think that I'm in theory open to suppress such warning on the next line also to make cppcheck backwards compatible. There is a small risk though that you suppress an other warning than intended.

[David Keegan]

I've read section 6.5 of the manual. It is not clear on the situation where there is code on the same line as the suppression AND on the following line. Does the suppression apply to both pieces of code, or just the code on the same line? I would expect code on the same line to take precedence,
and that seems to be the case.

I think it would be helpful if the manual was explicit about this, and about the fact that a standalone brace "{ " is interpreted as code.

I think interpreting a standalone brace as "code" doesn't make a lot of sense, but I can see how it arises. It is breaking backward compatibility for me. Is there ever a situation where a suppression applied to a brace actually triggers a warning?

[Daniel Marjamäki]

ok I will make a tweak for backwards compatibility.. maybe we will deprecate that at some point later but it will not be deprecated suddenly.

I've made a update to the manual:

https://github.com/danmar/cppcheck/commit/7ff6d691e27fd8fec8b3ed9526109b4ce70ea8b5

[Daniel Marjamäki]

If you want to see the PDF you can go here:

https://github.com/danmar/cppcheck/actions/runs/284582609

Download the "output" artifact and extract that then you should see the PDF.

[David Keegan]

I've read the updated manual, and it represents a really good solution. Thank you.

[David Keegan]

I've run the latest cppcheck code with your backward compatibility change against my codebase and it works as expected. Thanks again for fixing this issue.