[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bug#870: Repeatable instance of bug#870
From: |
Kenichi Handa |
Subject: |
Re: 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 <address@hidden>, Jason Rumney <address@hidden> 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
address@hidden
Re: bug#870: Repeatable instance of bug#870,
Kenichi Handa <=