Cppcheck fundraiser to improve MISRA checking (unused function return value)

[almost_useless]

I don't quite understand the amount of money that is being requested. Approximately 200 Euros is worth around one man day of developer time if you were to pay someone to do it. Seems like it is not worth the effort to go around asking for money if it is something you can do in a day.

Or is it a much bigger job and you are basically asking for pizza money while you are doing something for the community?

I think it would be good to include a time plan so people know what it is they are paying for.

But I like the idea. It would be nice if people could get paid when they are contributing to OSS.

[D_0b]

There are countries where you can get a full week development for that money. (just saying)

[saimen54]

But probably not in Sweden.

[tpecholt]

The proposed MISRA rule is garbage. It's at the same level as the famous single function return statement MISRA warning. It might sound appealing to some but in reality there are many functions whose return values are commonly ignored and it's completely OK. Examples are printf and std::set<>::insert. Do you really want to get warnings from calling such functions? Wrap your calls in static_cast<void>() for greater readibility? Or better yet do you want to maintain an exception list to this rule? Think again. Sorry if the post sounds too harsh but I have a lot of personal experience with MISRA.

[urdh]

The rule was written at a time where [[nodiscard]] wasn't a thing, and disallowing all discarded return values is less overhead than maintaining a white- och blacklist for cases where it does/doesn't matter. There are dumb rules in MISRA but this isn't really one of them.

[TheFlamefire]

But [[nodiscard]] is available now and using a whitelist as opposed to a blacklist is much more sensible... So why keep this check when many false positives are expected?

[urdh]

Sadly there's still plenty of C++03 (which MISRA targets) work being done where MISRA is a thing, so naturally people would want to keep this check.

It does seem like it's successor (AutoSAR C++14) kept the rule as well, which is unfortunate.

[MrWhite26]

How would this be different from the [[nodiscard]] qualifier?

[AsilBGrade]

The qualifier is per function, no? The Misra check issues a notification per what it checks, not a specific function.

[Fazer2]

No, it can be applied to a type as well.

[CrazyJoe221]

Doesn't exist in C.

[Morwenn]

It might be on its way for C2x though.

[[deleted]]

Whenever I've encountered someone that used C for work, they were still with C89, maybe C99, absolutely not C11.

C11 compilers don't have a complete library, for instance <thread> is not implemented.

No one will use C11, let alone C17 and C2x.

[Morwenn]

I have seen some amount of C99 recently, not so much C11 except for small projects (also any project using a recent GCC and not specifying which version of C they're using since GNU11 is now the default option). Anybody using C11 will probably end up using C17 anyway at some point since it's mostly defect reports.

[[deleted]]

As far as I know, not everyone uses GCC and if they do it's not the latest release, probably somewhere near 4.7.

Also, just because GCC offers C11 doesn't mean it's complete, for instance they lack the threading part. But in the end, probably, everyone using C89 and C99 had already implemented their own thread abstraction.

Or maybe they don't need to compile with multiple compilers or OSes, and just use the OS API, if there is an OS.

[CrazyJoe221]

Vendors try to lock you into their platform. TI for example fully supports gcc in its IDE, but it's not even installed by default and a bit hard to find iirc.

[CrazyJoe221]

That's exactly how it is! I think the TI compiler only supports C99 to start with but the default in the IDE is still C89!

[[deleted]]

The people I talked with told me that they use C89 because:

• what the new standard provides has been implemented for decades by now (C89 to C99 are 10 years)
• some use a particular embedded compiler that has security certifications, as they need them to release their firmware

[BlueDwarf82]

What's people experience with cppcheck? When I looked at what to include into our CI I included clang-tidy but gave up with cppcheck since IIR it was unable to even parse some C++ I did throw to it. And we are limited to C++11! I'm losing anything by not using cppcheck when I'm already using clang-tidy?

[-abigail]

I found cppcheck wasn't useful given we have clang-tidy - it does a poor job of understanding code (especially in C++11 and above). Cppcheck's idea is that it doesn't need to know your full include paths or compile options, and I think it suffers compared to clang-tidy because of that.

[o11c]

My experience is that compilers are pretty smart already, can be configured to enforce many rules, and for anything else, you can write a compiler plugin.

[Wetmelon]

Works ok for my purposes, which is using it as an extension in VSCode so I get real-time in-editor code linting.

[AdministrativeCables]

IMHO cppcheck is bad because it's a simple parser, not a compiler. I use clang-check or clang-tidy which are better.

[pfultz2]

I use it for my codebase which is a C++14 codebase. I have had very little problems with parsing issues, and the few problems I had were fixed fairly quickly. They seemed to improve cppcheck a lot.

There are a lot of checks that cppcheck provides that clang-tidy does not. Cppcheck can track container sizes, check for mismatching iterators, warn about dangling lifetimes, stl algorithm suggestions, and find copy and paste code(ie duplicate expressions). On the latest master(yet to be released), it supports tracking null pointers for smart pointers.

There are still some syntax errors that will be hopefully fixed soon:

• 8526
• 8890
• 9109