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.


Nmh-workers mailing list

Reply via email to