On Wed, Feb 25, 2026 at 05:57:24PM +0800, Kevin J. McCarthy wrote:
> The latest version changes string search functions, such as strchr()
> and strrchr(), so that the return type is the same type as the string
> passed in.
>
> This helped us catch a real bug in browser.c (3a8dfafc), and also
> turned up some variable type issues, fixed here.
>
> Thanks to Rene Kita for the work on the Arch sr.ht build files which
> turned up the bugs, and for an initial patch showing where the warning
> were, which this commit is based upon.
>
> Also thanks to Alejandro Colomar for quickly explaining what was going
> on and helping debug the issues.
> ---
> mh.c | 6 ++++--
> muttlib.c | 3 ++-
> parse.c | 5 +++--
> rfc1524.c | 7 ++++---
> sendlib.c | 3 ++-
> url.c | 10 ++++++----
> 6 files changed, 21 insertions(+), 13 deletions(-)
LGTM! Works in sr.ht CI with one more minor problem, which was not on my
list.
rfc2047.c: In function ‘try_block’:
rfc2047.c:331:5: error: the comparison will always evaluate as ‘true’ for the
pointer operand in ‘(const char *)&RFC2047Specials + 13’ must not be NULL
[-Werror=address]
331 | assert (strchr (RFC2047Specials, '?'));
| ^~~~~~
cc1: all warnings being treated as errors
Where RFC2047Specials is defined as
const char RFC2047Specials[] = "@.,;:<>[]\\\"()?/= \t";
in line 68 of the same file. Is there anything special about '?' here?
As long as no dev drops it from RFC2047Specials this assert will always
be true and does not make sense in my eyes.
I would drop it in a separate patch when sending the patch for the Arch
manifest.
I already run shellcheck in the Arch builds, I will wait till the shell
stuff is merged before sending it.
