Hi David, > Might Ken's commit adfed5f72bc07ac7de8dfc62188338d4d4f25a38 have fixed > this?
Yes, indeed. I get identical output from iconv(1) and mhshow(1) with the function from http://git.savannah.gnu.org/cgit/nmh.git/tree/uip/mhshowsbr.c. > + if (errno == EINVAL) { > + /* middle of multi-byte sequence */ > + if (write (fd, dest_buffer, outbytes_before - outbytes) < 0) { > + advise (dest, "write"); > + } > + fseeko (*fp, -inbytes, SEEK_CUR); Interestingly, that seeking back by the 1 unprocessed byte of input so the top-of-loop's fread can take another whole 8KiB triggers fseeko(0xaf20d0, -1, 1, 0x7f1c02ff3530 <unfinished ...> SYS_lseek(3, 4096, 0) = 4096 SYS_read(3, "\315\273\n5)"..., 4095) = 4095 <... fseeko resumed> ) = 0 __fread_chk(0x7fff69f40800, 8192, 1, 8192 <unfinished ...> 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. `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. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy _______________________________________________ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers