On Wed, Jun 17 2026, Dick Marinus wrote:
> It's recommended to store these functions in a const struct, for some
> reason I even got a segmentation fault without this.
The change looks sane (I also checked all references to reply_to_map in
code). With this the array does not need to create on-the-fly in that
function but can (even) be created to read-only location at compile-time
(barring binding to dynamic libs when program starts but still
mpu-protected...)
But about the commit message. Who recommends this thing? you? god?
deepseek? someone(tm)? Looks somewhat vague statement to me.
Then the sigsegv - I don't see why the code before that change would
sigsegv. Without more details so that it could be reproduced such
a statement should not be mentioned in commit message.
Tomi
PS. I am not against (L)LM -assisted coding, provided that the one
using is understands every change made by the "AI" tools. This is
a general statement and not suspecting whether this patch (series)
would not satisfy this :D
> ---
> notmuch-reply.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/notmuch-reply.c b/notmuch-reply.c
> index 44297251d..c72ca227e 100644
> --- a/notmuch-reply.c
> +++ b/notmuch-reply.c
> @@ -329,7 +329,7 @@ add_recipients_from_message (GMimeMessage *reply,
> GMimeMessage *message,
> bool reply_all)
> {
> - struct {
> + static const struct {
> InternetAddressList * (*get_header)(GMimeMessage *message);
> GMimeAddressType recipient_type;
> } reply_to_map[] = {
> --
> 2.54.0
>
> _______________________________________________
> notmuch mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
notmuch mailing list -- [email protected]
To unsubscribe send an email to [email protected]
