Quoting David Bremner (2026-02-21 12:59:07)
> > + tmp = (char *)realloc (filtered, filtered_len + bytes_read + 1);
> > + if (!tmp)
> > + goto FAIL;
> a hint about the memory allocation strategy would be good. I think last
> time I read this I worked out why realloc and not something fancier like
> talloc, but then a shiny thing distacted me...
The main reason is that _index_mime_part() (the caller of this code)
retrieves the body from gmime as a malloc'ed array, and hence frees it
with free().
The secondary reason is that, since this data is only created here and
then freed at the end of _index_mime_part(), using talloc would not
bring any benefits over traditional malloc/realloc/free.
> > +static void
> > +_filter_attachment (notmuch_message_t *message,
> > + const char *filter,
> > + const char *mime_type,
> > + const char *filename,
> > + char **pdata,
> > + size_t *pdata_len)
> > +{
> > + notmuch_database_t * const db = notmuch_message_get_database (message);
> > + const char *msgid = notmuch_message_get_message_id (message);
> > +
> > + char *data = NULL;
> > + size_t data_len = 0;
> > +
> > + pid_t pid = -1;
> > + int err = 0;
> > +
> > + const char *shell = getenv ("SHELL");
> > + const char *cmdline[] = { shell ? shell : "/bin/sh", "-c",
> > filter, NULL };
>
> Maybe you explained this already, but, why do we need/want to involve
> the shell? I assume there's a good reason not to just exec something
> like we for hooks?
We need some way of splitting the commandline into the argument list for
evecve(), a shell is the obvious way of doing that; I suppose we could
also make index.filter into a list option, IIRC I didn't know they
existed when I decided to use the shell. It would complicate the related
indexopts APIs though.
Thanks for the review.
--
Anton Khirnov
_______________________________________________
notmuch mailing list -- [email protected]
To unsubscribe send an email to [email protected]
