Subject: Re: [PATCH v2 11/11] ci: run expensive tests on push builds to integration branches

From: Patrick Steinhardt <[email-masked]>
Date: Thu, 7 May 2026 12:24:02 +0200

On Thu, May 07, 2026 at 06:18:34PM +0900, Junio C Hamano wrote:
> Johannes Schindelin <[email-masked]> writes:
> 
> >> I thought we updated the codebase to avoid stripping away constness
> >> with strchr() and friends, but the error seems to be more like one
> >> hand in the system passing -Wc11-extensions to stick to older version
> >> of C and the other hand in the system that uses _Generic to implement
> >> the const/non-const variants of strchr() in the system header not
> >> knowing that the other tells C11 const-preserving strchr() should not
> >> be used?
> >
> > This was diagnosed (with a proposed fix) by Patrick over in
> > https://lore.kernel.org/git/[email-masked]/.
> 
> Indeed.
> 
> > tl;dr It's not about `const`-ness at all, but about glibc using a C11
> > construct which clang's strict c99 checker now refuses, thanks to the
> > upgrade to Ubuntu 26.04 in the `ubuntu:rolling` runners.
> 
> Yes, that is exactly what I meant by one hand knowing that it was
> told not to use c11 extensions while the other hand ignoring and
> always using c11 extensions in the header.  I recall that in the
> past gnu library headers were a bit more careful to make the life
> more pleasant when we use (or decline to use) various features by
> using conditional compilation, but apparently not this case.

Yeah, it's a bit unfortunate indeed. I'd claim that this is a plain bug
though -- as mentioned in the commit message, I think what glibc should
have used is `_has_feature()` instead of `_has_extension()`,  and if so,
I think the issue wouldn't exist.

But oh, well.

Patrick