From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jason Rumney Newsgroups: gmane.emacs.devel Subject: Re: bug#870: Repeatable instance of bug#870 Date: Mon, 05 Jan 2009 18:59:03 +0800 Message-ID: <4961E7F7.2000509@gnu.org> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1231153199 9576 80.91.229.12 (5 Jan 2009 10:59:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 5 Jan 2009 10:59:59 +0000 (UTC) Cc: Emacs Devel To: Juanma Barranquero , 870@emacsbugs.donarmstrong.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 05 12:01:10 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1LJnCh-0008EA-Tz for ged-emacs-devel@m.gmane.org; Mon, 05 Jan 2009 12:01:06 +0100 Original-Received: from localhost ([127.0.0.1]:59169 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LJnBS-0000u1-Gr for ged-emacs-devel@m.gmane.org; Mon, 05 Jan 2009 05:59:46 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LJnBM-0000sP-59 for emacs-devel@gnu.org; Mon, 05 Jan 2009 05:59:40 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LJnBK-0000pa-4A for emacs-devel@gnu.org; Mon, 05 Jan 2009 05:59:39 -0500 Original-Received: from [199.232.76.173] (port=32986 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LJnBJ-0000p4-NA for emacs-devel@gnu.org; Mon, 05 Jan 2009 05:59:37 -0500 Original-Received: from ti-out-0910.google.com ([209.85.142.187]:55099) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LJnBJ-0002nk-3q for emacs-devel@gnu.org; Mon, 05 Jan 2009 05:59:37 -0500 Original-Received: by ti-out-0910.google.com with SMTP id u5so5777899tia.10 for ; Mon, 05 Jan 2009 02:59:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=7YgBD6i26p1sKqEe3Kq56RwSonuNaVaZDUXXQksM+UM=; b=NfH0F97rwUYp26g1qM/tH6zgwcAbmM3n2IUy0tJYv6OxdhWzIs+uc4bWcYwKkjuqUp zPRJHlB5gwpfsEVXd98YoZ8rfxNB0LDET8bmO9N1+qaDfKO728OyHmIkbN3ZbqIvrJvX dc07PAHXUSW08RY60BOX2u1CQI0dN9LITA23Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=gnFbi5kprmFfee9wVj28NnQmjf9vdaz0N2a+J82338M7NqUI3DmtM51B503cIG76fx MXQDEc+CORooe4tAa0v6DryjXxrFqU7D+45uv5bSqU21joXGitniv/NmeKBlcia+74Dc jwm4QT1qocP/FYZLzAiR1jDp7W+Bfk/QFks1s= Original-Received: by 10.110.5.18 with SMTP id 18mr8883045tie.16.1231153173410; Mon, 05 Jan 2009 02:59:33 -0800 (PST) Original-Received: from ?192.168.249.28? ([124.13.5.7]) by mx.google.com with ESMTPS id i6sm467133tid.36.2009.01.05.02.59.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 05 Jan 2009 02:59:32 -0800 (PST) User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) In-Reply-To: X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:107602 Archived-At: 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. 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.