How do we feel about Coverity Scan?

[Oppen]

Some years ago I played a bit with Coverity Scan for some personal (admittedly toy) projects and it looked like a good way to find hard to spot memory bugs (it catches a few more things IIRC, but those were the ones it shined the brightest). There's a free service for open source projects that we could take advantage of and in my experience it's far more sophisticated than tools like cppcheck, and slightly better at finding bugs than clang-analyzer. Go and Java are also supported, so it could also be useful for implementations on those languages.

The downsides:

1. Maintainers may be uncomfortable with relying on closed services;
2. It would be advisable to keep only a few developers on the loop, due to the risk of 0-days leaking before they're fixed otherwise. This could have some undesirable side-effects, some regular contributors may feel left out, picking who should or should not see the results could be hard, etc. The impact on the morale of the community could be bad (or I may just be too worried over nothing);
3. There's a limited number of builds per week. For the size of the project, it would be 28 builds a week, so a cron-like arrangement over main would probably be a better approach than, e.g., running on every PR.

So, what do other devs think? I'm interested in @lemire's opinion specially.

[lemire]

Though I have not used this particular service, I have used comparable ones in other projects.

It is good. More testing is better.

[Oppen]

Should I try and set it up? Maybe there's a way to give access to it to the RoaringBitmap org. I'm thinking of registering a non-blocking (in case we hit the weekly build limit) GH Action workflow on merge to main.

[lemire]

Should I try and set it up?

Please do.

[lemire]

@Oppen I have given you privileged access to the repository.

[Oppen]

I made a simple test, no automation yet. I'm fixing a few issues, I'll resume work during the weekend and try to get to a draft PR for automation (plus a PR for the fixes).