Re: [PATCH 2/2] ci: bump ubuntu image version for static-analysis job

From: Jeff King <peff@peff.net>
Date: Sep 5, 2026, 13:44 UTC
Message-ID: <20260905134424.GA3914039@coredump.intra.peff.net>
In-Reply-To: <anqs8mT78znJmUwJ@pks.im>

On Tue, Aug 11, 2026 at 07:02:42AM +0200, Patrick Steinhardt wrote:

Show 23 quoted lines

> On Mon, Aug 10, 2026 at 10:52:21AM -0700, Junio C Hamano wrote:
> > Patrick Steinhardt <ps@pks.im> writes:
> > 
> > > Taking a step back, I do have to wonder whether the Cocci files have
> > > been adding any kind of value in the first place. I myself introduced
> > > some of them in contexts where I made sweeping changes to our APIs, so
> > > that any in-flight topics can be trivially adjusted via Coccinelle. But
> > > I very much doubt that anyone ever used those to adapt their in-flight
> > > patch series at all.
> > >
> > > So maybe we should just not do that anymore?
> > 
> > We still do catch when somebody writes "if (a == NULL)", no?
> 
> Yes! What I was trying to say is that we maybe shouldn't add Cocci files
> for temporary migrations anymore, but still keep (and extend) them for
> evertyhing where we want to consistently catch antipatterns going
> forward.
> 
> Overall I have a feeling that I'm overthinking this though :) Maybe it
> ultimately doesn't matter too much and we just continue what we're doing
> and then clean up every once in a while when too much cruft has
> accumulated.

FWIW, I'd be happy to avoid coccinelle for transitions. The most important thing is for transitions to be brought to the developer's attention at all, so we don't quietly produce broken programs or continue adding callers of interfaces we're trying to get rid of.

But bringing attention is often done trivially via the compiler (e.g., changing names or interfaces). Coccinelle can further suggest the actual fix, but most of the time that fix is either obvious, or easily explained in the commit message (and I feel like if any project can do so, we should be able to assume people can use pickaxe/blame to find the source of a change).

So coccinelle can save some work in these cases, but I think it is a net loss overall compared to both the effort in writing the semantic patches, as well as the operational headaches.

I do think there's still enough value in the enforcement of rules that can't easily be caught by the compiler. Style bits like "a == NULL" are an obvious example, but I think we have some "we offer functions X and Y, but you should usually use X unless you have a good reason". Though maybe even some of those can be simplified (stuff like oidclr() should be preferred over hashclr(), but maybe we are at a point where hashclr() can become a private function?).

-Peff