bug#870: Repeatable instance of bug#870

[Kenichi Handa]

In article <E1LKMsw-0005wG-G6@etlken.m17n.org>, Kenichi Handa <handa@m17n.org> 
writes:

> > 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.

> ??? decode_coding_* gets bytes from coding->source and
> produces characters in CHARBUF.  So, I think the above
> analysis is not correct.

> As normal visiting of ChangeLog.870 doesn't have the problem
> but revisiting it causes the problem, I think the bug is in
> Finsert_file_contents; perhaps in the handling of REPLACE.
> I'll have a look at it.

I fixed the bug.  Actually what wrong was decode_coding_*
but in the different place as above.

---
Kenichi Handa
handa@m17n.org