Am Mo., 16. Feb. 2026 um 11:52 Uhr schrieb Martin Jambor <[email protected]>: > > Hello, > > On Mon, Feb 16 2026, Michael J Gruber wrote: > > Am So., 15. Feb. 2026 um 23:13 Uhr schrieb David Bremner > > <[email protected]>: > >> > >> Nicolas PARLANT <[email protected]> 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? Even after reading the above it's not clear what strrchr was before and - more importantly - whether the "fixed" code still compiles with strrchr() from older glibc. In an ideal world, commit messages are longer than the patch body ;-) Cheers, Michael _______________________________________________ notmuch mailing list -- [email protected] To unsubscribe send an email to [email protected]
