bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#870: Repeatable instance of bug#870


From: Kenichi Handa
Subject: bug#870: Repeatable instance of bug#870
Date: Wed, 07 Jan 2009 10:07:02 +0900
User-agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/23.0.60 (i686-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

In article <4961E7F7.2000509@gnu.org>, Jason Rumney <jasonr@gnu.org> writes:

> Juanma Barranquero wrote:
> >    emacs -Q --eval "(desktop-save-mode 1)" ChangeLog.870
> >   

> I can also reproduce the bug with C-x RET r utf-8-dos after visiting the 
> file normally.

I can reproduce it by that recipe.

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

---
Kenichi Handa
handa@m17n.org






reply via email to

[Prev in Thread] Current Thread [Next in Thread]