On Mon, Jan 5, 2009 at 11:59, Jason Rumney <jasonr@gnu.org> wrote:
It appears that there is a bug in all the decode_coding_* functions when a
CR lies on a CHARBUF_SIZE (0x4000) boundary with a matching LF on the other
side of the boundary.
They all do something like:
if (eol_crlf && c1 == '\r')
ONE_MORE_BYTE (byte_after_cr);
but ONE_MORE_BYTE will abort the decode if it reaches the end of the buffer,
leaving the CR in limbo between having been read and being added to the
buffer. Then on decoding the subsequent block, the initial LF does not trip
the normal CRLF decoding, so it is put into the buffer.
Wouldn't that mean that, on writing the buffer, the file would end
with extra CRs, instead of missing LFs?