On Sat, Dec 4, 2021 at 3:13 AM Jeff King <peff@xxxxxxxx> wrote: > We're not doing project-wide analysis with Coverity right now, but I've > been doing builds of my personal repo, which I usually build off of > next. And since hn/reftable just hit next, it got included in my latest > build. > > It came up with several complaints. Some of them are dumb and can be > ignored (e.g., using rand() in a test harness, oh no!) but I poked at a > few and they look like real issues: I fixed most of the obvious ones. > - A lot of your structs have vtables. Initializing them to NULL, as in > reftable_reader_refs_for_indexed(), leaves the risk that we'll try > to call a NULL function pointer, even if it's for something simple I have the impression that coverity doesn't understand enough of the control flow. Some of the things it complains of are code paths that only get executed if err==0, in which case, the struct members at hand should not be null. > I similarly wondered if these polymorphic types could be using a union > within reftable_record, rather than pointing to a separate stack > variable. Then you could initialize the whole thing without worrying > about intermediate NULLs (and also there's less pointer chasing and it's > a little bit more type safe than a void pointer). But again, I don't > know the code well enough to know if that would cover all of your cases. This is a great idea. I've made a change that does this, which I will post shortly. > The summary of issues is below. You can get more details on their site. > I _think_ I've configured it so that anybody can look at: > > https://scan.coverity.com/projects/peff-git/view_defects Alas, it says I have no access, even after I logged in. -- Han-Wen Nienhuys - Google Munich I work 80%. Don't expect answers from me on Fridays. -- Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
