archive-program

billions on projects. Nothing there for the average company, and especially not for (frankly often underfunded) OpenSource projects. So you understand my pain. To be more specific, OpenZFS is decently funded since its developers can get employment to work on it. However, I suspect that funding for tools like Abstree and PVS Studio is not there. Interestingly, PVS Studio claims to be free for open source projects, but then restricts the projects that may use it to hobbyist projects: https://pvs-studio.com/en/order/open-source-license/ I really doubt funding would be there for PVS Studio given that its blog suggests that companies purchase licenses for all developers. They did that with Google at the following link, in a way that suggested (as per my reading) that Google pay for licenses for Chrome developers working at other companies: https://pvs-studio.com/en/blog/posts/cpp/0559/ Getting 1 company to volunteer to pay for the licenses of all developers that work on an open source project is not a feasible proposition, since even if it were willing to pay for licenses, it would only be willing to pay for ones for its own developers. This conflicts with the idea that an OSS project should integrate static analyzers into continuous integration infrastructure to make defect reports available to all developers through pull requests. 1 developer handling all reports like we currently have with Coverity might seem like it would work around that, but it is a huge burden on that 1 developer. I know because I am currently that 1 developer. Their blog speaks fairly strongly against large groups getting a license for 1 developer who is responsible for all of the reports, so that seems unlikely to happen even if I were masochistic enough to volunteer to be that 1 developer: https://pvs-studio.com/en/blog/posts/0135/ That said, I have not yet finished processing reports from the free tools, so when I do, I would be pleasantly surprised should: 1. I try free trials of paid tools (mainly astree and PVS Studio) 2. I find that they are worthwhile to continue using. 3. I ask the community about obtaining funding to obtain those tools for our continuous integration infrastructure. 4. It actually happens. I strongly expect both Astree and PVS Studio to ask for astronomical numbers that the community is not going to fund. That is also why I keep delaying the use of their free trials, since I want to use them during a period where I am certain that I can make the most of them. I won't be able to make the most of them if I am still working on reports from other static analyzers, especially since those same reports might also be made by Astree and PVS Studio. > CodeQL? It's mostly an semantic search and replace tool, as I know? Is it that helpful? (I had a look, but the projects I'm working on don't require it. One would just use the IDE. No need for super large-scale refactorings, across projects, in our case). I have never heard about a semantic search and replace function in CodeQL. Perhaps you are thinking of Coccinelle? CodeQL is a static analyzer whose checks are written in the CodeQL language. However, it is very immature. When github acquired it, they banished the less reliable checks to the extended-and-security suite, leaving it only with about ~50 checks for C/C++ code. Those catch very little, although in the rare instances that they do catch things, the things caught are somewhat amazing. Unfortunately, at least one of those checks provides technically correct, yet difficult to understand, explanations of the problem, so most developers would dismiss its reports as false positives despite it being correct: https://github.com/github/codeql/issues/11744 There are probably more issues like that, but I have yet to see and report them. > SonarCloud, hmm… This one I've used (around web development though). But am not a fan of. It bundles other "scanner" tools, with varying quality and utility. At least what they had for the languages I've actively used it was mostly about "style issues". And when it showed real errors, the IDE would do the same… (The question then is how this could be committed in the first place. But OK, some people just don't care. For them you need additional checks like SonarCloud I guess.) It is supposed to be able to integrate into github's code scanning feature, so any newly detected issues are reported in the PR that generated them. Anyway, it is something that I am considering. I wanted to use it much sooner, but it required authorization to make changes to github on my behalf, which made me cautious about the manner in which I try it. It is basically at the bottom of my todo list right now. > Wouldn't it be easy to add at least this to the build by using some "build container"? I do not understand your question. To use it, we need a few things: 1. To be able to show any newly introduced defect reports in the PR that generated them shortly after it was filed. 2. To be able to scan the kernel modules since right now, it cannot due to a bad interaction between the build system and how compiler interposition is done. As of a few days ago, I have a bunch of hacks locally that enable kernel module scans, but this needs more work. 3. An easy way to mark false positives without doing commits. Without those things in place, it is a dead on arrival proposition. OpenZFS already tried using CPPCheck without #1 and #3 in place and it was so painful that the project reversed course. That happened while I was on a multi-year sabbatical from the project, so I only know about it from seeing traces of it in the repository and asking others who were around for it about what happened. > Well, that's why I think something equivalent to `-Wall -Werror` should be switched on before writing the first line of code, in any language. OpenZFS has had that in place for more than a decade. I do not know precisely when it was first used (although I could look if anyone is particularly interested), but my guess is 2008 when ZFSOnLinux started. Perhaps it was done at Sun before then, but both events predate me. I became involved in 2012 and it is amazing to think that I am now considered one of the early OpenZFS contributors. Interestingly, the earliest commits in the OpenZFS repository referencing static analysis are from 2009 (with the oldest commit being from 2008 when ZFSOnLinux started). Those commits are ports of changes from OpenSolaris based on defect reports made by Coverity. There would be no more commits mentioning static analysis until 2014 when I wrote patches fixing things reported by Clang's static analyzer. Coverity was (re)introduced in 2016. As far as the current OpenZFS repository is concerned, knowledge of static analysis died with OpenSolaris and we lost an entire form of QA until we rediscovered it during attempts to improve QA years later. That said, if you have suggestions to improve QA, I am willing to listen to them, although keep in mind that it takes time for me to do things, even if I think they are good ideas, and I already have a large number of ideas to implement since returning to the project earlier this year. > But I guess I will stay with engraving my data into solid rock. Proven for at least hundred thousand years. That method is no longer reliable due to acid rain. You would need to bury it in a tomb to protect it from acid rain. That has the pesky problem of the pointers being lost over time. > At least someone needs to preserve the cat pictures and meme of our current human era for the cockroach people of the distant future. I'm not sure they will have a compatible Linux kernel and compiler available to build the ZFS drivers, or even punch card readers… Github's code vault found a solution for that, although they used it on source code: https://github.com/github/archive-program/blob/master/GUIDE.... I vaguely recall another effort trying to include the needed hardware in time capsules, but I could be misremembering.