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
pgpaaaFmNK3bs.pgp
Description: PGP signature
_______________________________________________ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch