Okay, I guess I could see that. The normal case would be to decode
the contents completely
Yep, to UTF-8 single lines?
Well, to whatever the local character set is.
Well, you might be thinking the 2047-decoding might not make a lot of
difference, whereas I'm thinking a block can be read into a page-aligned
buffer that has an \n beyond it as a sentinel, then check for
/foo[ \t]*:/i, ignore any non-foo headers, hunt for the next \n and repeat
if it's not the sentinel, else read another block and try again. Stop
if no more blocks or \n\n. The detail's a bit more complex but there's
no allocation and copying for headers seen along the way; they'll be
found when they're looked for in turn. The file's blocks aren't being
modified so no copy-on-write's occurring.
Sigh. I wasn't actually thinking of special-casing pick. If pick wants
a particular header, it can search through Content->c_first_hf for it.
We can put a hash table or some other indexing in there if you want it.
But my mental plan was that there was always going to be allocations.
If pick gets noticably slower then we can revisit this idea.
(As an aside, I see that pick does use ^foo[ \t]*: to match on a header,
but my reading of RFC 5322 is that spaces are not allowed between the
header name and the colon ... but I guess the old syntax did?)
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers