cppcheck / Discussion / General Discussion: Next cppcheck release?

Alastair Donaldson - 2021-05-17

I use cppcheck in the CI for one of my projects - it's a great tool, thanks!

I check out the tag for the latest release and build it during CI.

Recently the build started to fail due to lib/symboldatabase.cpp missing an #include of <limits> - I think something in my CI setup changed which had previously been preventing this from causing a compilation error.

I notice that this has been fixed in main, and I wondered whether a cppcheck release is imminent? (If not I can change my CI to pin to a particular commit but I'd rather pin to a release).

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Daniel Marjamäki - 2021-05-17

it will take a while before the release. I feel that latest head is rather experimental.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Richard Smith - 2021-05-17

The cppcheck project really needs to start providing a stable branch instead of always requiring an update to the current development to get any bug fixes. Not having a stable branch with bug fix backports is really big PITA for me.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Daniel Marjamäki - 2021-05-18

I am not against providing a stable branch if there are critical problems in the release. We can definitely add the include in the 2.4.x branch.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Richard Smith - 2021-05-19

I suppose that depends on the definition of a critical problem. I am currently unable to use any version > 2.3 because of the breakage that occurs due to MISRA rule 9.5. Our build/CI system depends on passing cppcheck. So from my view 2.4 is a serious regression. Would you see that as a critical problem?

In general updates to cppcheck have been extremely problematic and frustrating. Release to release the behavior of cppcheck changes with no warning or deprecation period. Breaking rule changes occur with no (easy) way to revert the newer versions to back to the behavior of the older version.
EVERY time I have updated cppcheck our build system breaks due to cppcheck for some reason or another. If there is a upstream fix on a false positive I'm forced to choose between keeping the FP suppressed and updating and then sorting out the breakage.

As a developer I understand that sometimes breakage happens but as a user I find it extremely frustrating that i have often have to run development versions just to get a bug fix I would like.

A stable version that backported bug fixes and FP fixes only would go a long way at helping to improve the update experience.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Daniel Marjamäki - 2021-05-19

Would you see that as a critical problem?

Not sure. I feel I don't know what problem you are talking about exactly. The misra addon was broken up into 2 files .. right.

If some file that is needed is missing in the installation that would be rather critical. If you can't run the tool at all that would be critical. If we have a missing include <limits> I feel that is critical.

Release to release the behavior of cppcheck changes with no warning or deprecation period.

This feels like a valid criticism. I am trying to think about this. But I know I have changed behavior too easily sometimes. :-(

EVERY time I have updated cppcheck our build system breaks due to cppcheck for some reason or another.

ouch :-( .. very sorry to hear that. is it addons-related problems typically? We use Cppcheck at my work also and I update the CI scripts now and then.. and I feel that typically it works well. The problems I get are "expected" (false positives / false negatives) I have not seen problems because the interface has changed drastically.. However no addon is used at my work.

A stable version that backported bug fixes and FP fixes only would go a long way at helping to improve the update experience.

Backporting every FP fix would not be very reasonable.

I don't know if we can somehow be more careful in our release process. Can we somehow detect that there will be upgrade problems.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Richard Smith - 2021-05-21
  
  Would you see that as a critical problem?
  
  Not sure. I feel I don't know what problem you are talking about exactly. The misra addon was broken up into 2 files .. right.
  
  It throws an exception on my codebase and on someone elses.
  
  See these discussions:
  
  <snip></snip>
  
  I had links but the spambot protection stopped me. See the following message subjects.
  
  Cppcheck internalError on MISRA C rule 9 in discussions
  and
  Cppcheck-2.4 in devleopment.
  
  ouch :-( .. very sorry to hear that. is it addons-related problems typically?
  
  It's been both but the majority of the problems have been with the MISRA addon throwing exceptions. There as also some interface changes that removed existing options.
  
  Things were also complicated that there was (but I haven't checked lately) different behavior when the addon was run directly via cppcheck vs external on the .dump files. I have things set up now for using the in-process call though so this is not so much of a complication for me anymore.
  
  A stable version that backported bug fixes and FP fixes only would go a long way at helping to improve the update experience.
  
  Backporting every FP fix would not be very reasonable.
  
  I said 'backporting' but that was actually the wrong term to use. The way this is accomplished it to invert the workflow. Instead of backporting from main you use stable as the reference for resolving FPs and bugs. Those get fixed against the stable branch first and then you forward port them to main. There are many projects that do this. Git itself is one of the most notable. This is the "merging upward" workflow. It works and is not hard to do. I use this same flow in my team for our firmware releases.
  
  I recognize that some FP fixes may require a very large rewrite and that is understandable. Those would require a new release but I believe those will be the minority of changes.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

CHR - 2021-05-20

How about a public beta a couple of weeks ahead of a release? I think this would help catching all kinds of regressions, FPs and so on.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Daniel Marjamäki - 2021-05-20
  
  that sounds very good to me.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Richard Smith - 2021-05-21
  
  Yes this would be good. A series of -rc releases ahead of an actual release would allow testing for regressions.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Next cppcheck release?

Static source code analysis tool for C and C++ code

Forums

Help

Next cppcheck release?

Next cppcheck release?

Static source code analysis tool for C and C++ code

Forums

Help

Next cppcheck release? document.SUBSCRIPTION_OPTIONS = { "thing": "topic", "subscribed": false, "url": "subscribe", "icon": { "css": "fa fa-envelope-o" } };

Next cppcheck release?