Re: Minor cleanup after adding more warnings to CFLAGS

"Kevin J. McCarthy" <[email protected]> Mon, 30 Mar 2026 09:58:57 +0800

Newsgroups	gmane.mail.mutt.devel
Message-ID	<acnY4RwPeffcqfT6@qinghai>

On Sun, Mar 29, 2026 at 05:36:52PM +0200, Rene Kita wrote:
>Below is the shortened build log with the remaining errors after my 9
>patches were applied. Adding more const to avoid these errors leads to
>more errors somewhere else in the call chain. There are other errors
>which come from -Wtype-limits and -Wredundant-decls.

I'll take a closer look at these later today when I have more time.

>Most prominent example is imap_next_word which is called in a lot of
>functions taking const char * as an parameter. We do cast away the const
>there. imap_next_word does not modify the string, but will return the
>string in the end. This means if we let imap_next_word take a const
>char * we also need to return a const char *. But this does not work
>everywhere it is used.
>
>What is the general opinion here regarding such compiler flags and how
>to handle such situations?

The imap_next_word() is traversing a mutable stream of characters. 
Several places modify that stream as they "parse" the IMAP results.  So 
changing imap_next_word() argument/return type would just make thing 
even more complicated.

The problem are the various helper functions, like imap_cmd_trailer(), 
cmd_status(), cmd_parse_myrights(), cmd_parse_search(), 
cmd_parse_enabled().  Yes, they aren't modifying the char* and are 
trying to be helpful by noting that.  But it gets complicated when they
intertwine with imap_next_word().

I have to confess I'm not proficient with the sharp edges of const 
usage.  If we want to remove the warnings (and I'd love to hear others' 
opinions about this), then I would vote for removing the const from 
those helper functions.

-- 
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA

signature.asc (application/pgp-signature, 833 B)