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

[Jeff King <peff@peff.net>]

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

> 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