GNU bug report logs - #870
Missing ^J in ChangeLog

Previous Next

Packages: emacs, w32;

Reported by: "Juanma Barranquero" <lekktu <at> gmail.com>

Date: Wed, 3 Sep 2008 11:10:05 UTC

Severity: normal

Done: Jason Rumney <jasonr <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Kenichi Handa <handa <at> m17n.org>
To: Kenichi Handa <handa <at> m17n.org>
Cc: jasonr <at> gnu.org, lekktu <at> gmail.com, 870 <at> debbugs.gnu.org,
        emacs-devel <at> gnu.org
Subject: bug#870: Repeatable instance of bug#870
Date: Wed, 07 Jan 2009 15:53:48 +0900
In article <E1LKMsw-0005wG-G6 <at> etlken.m17n.org>, Kenichi Handa <handa <at> 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 <at> m17n.org




This bug report was last modified 16 years and 129 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.