Ralph wrote:
Hi David,
Might Ken's commit adfed5f72bc07ac7de8dfc62188338d4d4f25a38 have fixed
this?
Yes, indeed.
Great! We'll get you to the bleeding edge yet.
IOW, it seeks to 4Ki and reads 4Ki - 1 so it's left in the right place
to read the one byte, that we already have, next time. An alternative
to sliding down the remaining unprocessed input with memmove(3) and
shortening the next fread, I suppose.
This shouldn't happen very often, so I'd lean toward the simpler code.
`strace -e desc mhparam foo' shows many lseek(2)s to get the current
position on .mh_profile; always the same. Triggered by the infamous
m_getfld()'s ftello(3). :-) Must trigger for every header of every
email processed too.
Yes, m_getfld() could use another rewrite. Though the last one really
wasn't, I tried to maintain the existing logic to avoid too many
simultaneous changes.
David
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers