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@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
