Re: [PATCH 2/2] format-patch: fix leak of rev_info in prepare_bases()

[Patrick Steinhardt <ps@pks.im>]

On Sun, Jul 05, 2026 at 08:34:29PM -0400, Jeff King wrote:
> On Fri, Jul 03, 2026 at 01:45:15PM -0700, Junio C Hamano wrote:
> 
> > Patrick Steinhardt <ps@pks.im> writes:
> > 
> > >> Likewise I find the dual clang/gcc jobs to be overkill. Compiling with
> > >> both is useful, as they have different warnings. But have we ever seen a
> > >> case where running the tests showed a different result with different
> > >> compilers?
> > >
> > > Not that I'd know of. As you say, I think it makes sense to use
> > > different compilers in general. But I don't really think we need to have
> > > this as a full "compiler x tests" matrix.
> > 
> > Very true.  Different configurations with TEST-vars are great
> > combination to test, but we are not in the business of hunting bugs
> > in clang/gcc so we long as they compile (instead of warning "hey,
> > that construct gives you undefined behaviour"), we shouldn't have to
> > run the test suite with the same configuration for both.
> 
> I don't care about finding bugs in clang vs gcc. I'm more concerned with
> a case where we have undefined behavior, both compile it fine, but the
> bad behavior is revealed in the tests only by one of them.
> 
> I can think offhand of only one case where I saw that happen[1]. IIRC it
> had to do with integer sizes being passed to a variadic function. But it
> also changed behavior within the same compiler using different
> optimization levels. So it feels like kind of a scattershot way of
> trying to flush out UB, and we are probably better off with UBSan and
> friends.

Yes, I just wanted to say that UBSan is definitely the better way to go
in this context. I have no idea of course whether it would have catched
the mentioned issue, though.

And even so, we'd have at least one job that runs all tests with either
of the compilers, so we'd still notice issues like that.

Patrick