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
Description: PGP signature
