Re: [PATCH v2 11/11] ci: run expensive tests on push builds to integration branches
- From
Patrick Steinhardt <ps@pks.im>
- Date
- May 7, 2026, 10:24 UTC
- Message-ID
- <afxoQh8SxCqBCaFP@pks.im>
- In-Reply-To
- <87se83efx1.fsf@gitster.g>
On Thu, May 07, 2026 at 06:18:34PM +0900, Junio C Hamano wrote:
Show 25 quoted lines
> Johannes Schindelin <Johannes.Schindelin@gmx.de> 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/20260505-b4-pks-ci-tolerate-glibc-generic-v1-1-5786386fe512@pks.im/. > > 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