Re: [PATCH 2/2] lib: fix glibc-2.43 w/ clang

Subject: Re: [PATCH 2/2] lib: fix glibc-2.43 w/ clang

Date: Mon, 16 Feb 2026 14:22:47 +0100

To: Michael J Gruber

Cc: Nicolas PARLANT, notmuch@notmuchmail.org

From: Martin Jambor


Hello,

On Mon, Feb 16 2026, Michael J Gruber wrote:
> Am Mo., 16. Feb. 2026 um 11:52 Uhr schrieb Martin Jambor <mjambor@suse.cz>:
>>
>> Hello,
>>
>> On Mon, Feb 16 2026, Michael J Gruber wrote:
>> > Am So., 15. Feb. 2026 um 23:13 Uhr schrieb David Bremner <david@tethera.net>:
>> >>
>> >> Nicolas PARLANT <nicolas.parlant@parhuet.fr> writes:
>> >>
>> >> >>notmuch-insert.c:136:11: error: assigning to 'char *' from 'const char *'
>> >> >>      discards qualifiers
>> >> >>      [-Werror,-Wincompatible-pointer-types-discards-qualifiers]
>> >> >>  136 |     slash = strrchr (path, '/');
>> >> >>      |           ^ ~~~~~~~~~~~~~~~~~~~
>> >>
>> >> Thanks for the patch. The change itself looks fine, but the (subject of)
>> >> the commit message is a bit cryptic. We use "lib:" for code in the lib/
>> >> or (maybe util/) directory. This is obvious not a fix for glibc, but
>> >> that's what a naive reader (like me) might think.
>> >
>> > That makes two of us :)
>> >
>> > Also: How is the patch related to glibc version? Has the declaration
>> > of strrchr() changed?
>>
>> See https://sourceware.org/pipermail/libc-alpha/2026-January/174374.html
>> specifically:
>>
>>   * For ISO C23, the functions bsearch, memchr, strchr, strpbrk, strrchr,
>>     strstr, wcschr, wcspbrk, wcsrchr, wcsstr and wmemchr that return
>>     pointers into their input arrays now have definitions as macros that
>>     return a pointer to a const-qualified type when the input argument is
>>     a pointer to a const-qualified type.
>>
>> (and similar items in the list)
>
> Thanks for the link.
>
> The main point is still about being clear in the commit message: "Fix"
> indicates something is broken. What is broken? Is this a warning with
> clang, an error leading to build failure in default settings or with
> -Werror?

I have not actually looked, but I expect the problem is that notmuch
contains code which passes a const char pointer to strchr but stores the
result in non-const-qualified char pointer.  That is valid C17 but not
valid C23.  With glibc 2.43 now conforming to this aspect of C23 and
with modern compilers (also GCC 15, for the record) now defaulting to
C23, you get compilation errors, no -Werror needed.

At least that is the common case in many other packages, as I wrote, I
did not specifically look into this one.

Martin
_______________________________________________
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org

Thread: