On Fri, 09 Apr 2010 15:53:04 -0700, Dirk Hohndel <hohn...@infradead.org> wrote:
> + * WARNING - if the caller is asking for a header that could occur
> + * multiple times than they MUST first call this function with a 
> + * a value of NULL for header_desired to ensure that all of the
> + * headers are parsed and concatenated before a match is returned
...
> +     } else {
> +         /* not sure this makes sense for all headers that can occur
> +          * multiple times, but for now just concatenate headers
> +          */
> +         newhdr = strlen(decoded_value);
> +         hdrsofar = strlen(header_sofar);

I'm a little nervous about this semantic change.

For example, I know that my mail collection contains at least some
messages with multiple Message-ID headers, (I'm not sure that's legal,
but they are there). I found those when doing detailed comparisons of
the database created by sup with that created by very early versions of
what became the indexing code for notmuch. [Sup prefers the
last-encountered Message-Id in the file, while Notmuch prefers the
first.]

So I'm concerned about the change above introducing subtle problems that
might be hard to notice.

How about an argument that asks explicitly for concatenated header
values, (and this could just trigger a rescan of the headers and ignore
the hash). I think that will be fine for your use case where you're just
opening this message file to get this one concatenated header out,
right?

-Carl

Attachment: pgpaaaFmNK3bs.pgp
Description: PGP signature

_______________________________________________
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Reply via email to