Choosing an other analysis default setting for checking of function return values

[Markus Elfring]

The manual contains the following information.

…
        <para>As long as nothing else is specified, cppcheck assumes that
        ignoring the return value of a function is ok:</para>
…

How do you think about to change this default setting by a program parameter so that unused function return values would be treated as suspicious?

[Daniel Marjamäki]

The Cppcheck philosophy is to be silent when we don't see a bug. through configuration you can fix false negatives.

[Markus Elfring]

Can this “silence” become a target conflict for more helpful source code analysis?

[versat]

IMHO it would be nice if it is possible to tell Cppcheck how to behave. More strict and noisy with false positives or less strict and more silent with few false positives.
I created the ticket 8389 to request this and suggest configuration enhancements.
I have worked with PC Lint which is very noisy and complains about every unused return value until told otherwise. This could be very useful. But it is sometimes hard to find the real problems between thousands of messages.

[Markus Elfring]

Thanks for the link to the issue “Feature request: Pedantic/Strict mode for critical software”.
I became also curious on consequences for source code analysis configurations.
How will further system fine-tuning evolve here?

[Daniel Marjamäki]

IMHO it would be nice if it is possible to tell Cppcheck how to behave. More strict and noisy with false positives or less strict and more silent with few false positives.

this is discussed now and then. I am not against it in principle. But you have to realize that you have implement these checkers from scratch. The existing checkers are designed to avoid FP.

All Cppcheck infrastructure is tuned to avoid false positives. The ValueFlow analysis is not noisy. The configuration in the cfg files are not noisy. etc.

You can implement a addon that checks that the return value is always used. And you could then add other noisy checks to that addon. I would not be against adding such addon in the repo.

[Markus Elfring]

But you have to realize that you have implement these checkers from scratch.

I hope that this software situation can change more.

And you could then add other noisy checks to that addon.

How much deviations will be tolerated from Cppcheck's original goals for the mentioned purpose?

[Daniel Marjamäki]

I wonder if bugprone-unused-return-value in clang-tidy works? Since it uses the real compiler AST it should be able to catch more bugs than we could in Cppcheck.

[Markus Elfring]

This functionality is described in a way where I see high system configuration efforts.
I imagine that more return values should usually be checked than ignored.

• Will it be more convenient to specify the circumstances for exceptions with return value usage instead?
• Would you like to compare source code analysis efforts between the management of white- and black-lists any more?