> 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
Nmh-workers mailing list