Subject: bug#5251: closed (Re: bug#5251: 23.1; problem in decode_eol of coding.c)

From: [email-masked] (GNU bug Tracking System)
Date: Wed, 17 Feb 2016 15:54:02 +0000

Your bug report

#5251: 23.1; problem in decode_eol of coding.c

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
5251: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5251
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#5251: 23.1; problem in decode_eol of coding.c
From: Eli Zaretskii <[email-masked]>
To: Andrew Hyatt <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Wed, 17 Feb 2016 17:53:41 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

> From: Andrew Hyatt <[email-masked]>
> Date: Tue, 16 Feb 2016 22:41:32 -0500
> Cc: [email-masked]
> 
> 
> I can verify that this issue still happens in Emacs 25.  This simple fix
> seems to have slipped by unnoticed many years ago, hopefully someone
> that is qualified to comment on the patch will see it now.

Thanks for the reminder, I fixed this now on the emacs-25 branch.
(The proposed patch was not entirely correct, although it was in the
right direction, and happened to fix this particular case.)

It is indeed a shame that such a simple bug was left unresolved for
such a long time, but better late than never.

> BTW, this seems like a nice thing to unit test with ert, if a fix does
> take place.

Yes, that would be very welcome, thanks.  Looks like coding-tests.el
is a good place to add such a test.  Please be sure to include lone ^M
characters, as well as those followed by a newline, so that we are
sure lone CRs are not removed.

Thanks.

>From MAILER-DAEMON Sun Dec 20 15:10:20 2009
Mail-Followup-To: Toru TSUNEYOSHI <[email-masked]>,
	[email-masked]
Resent-From: Toru TSUNEYOSHI <[email-masked]>
Original-Sender: [email-masked]
Resent-To: [email-masked]
Resent-CC: [email-masked]
Resent-Date: Sun, 20 Dec 2009 19:42:02 +0000
Resent-Message-ID: <[email-masked]>
Resent-Sender: [email-masked]
Date: Sun, 20 Dec 2009 17:57:09 +0900
To: [email-masked]
From: Toru TSUNEYOSHI <[email-masked]>
Sender: [email-masked]
Resent-Date: Sun, 20 Dec 2009 14:42:02 -0500
Cc: 
Subject: bug#5251: 23.1; problem in decode_eol of coding.c
Reply-To: Toru TSUNEYOSHI <[email-masked]>, [email-masked]

----Next_Part(Sun_Dec_20_17_57_09_2009_140)--
Content-Type: Text/Plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit

In GNU Emacs 23.1, there is a problem in decode_eol of coding.c.

In buffer of which enable-multibyte-characters is nil,
the function `decode-coding-region' should delete the character '^M'
(code: 0x0d) at the end of line,
in case that the function parameter `coding-system' is *-dos (and
the variable `inhibit-eol-conversion' is nil).
But, in practice, the function doesn't delete all of the character '^M'.

You can watch the problem with the following.

========================================================================
(progn
  (pop-to-buffer (generate-new-buffer-name "*scratch*"))
  (set-buffer-multibyte nil)
  (insert (encode-coding-string "あ" 'euc-jp) "\xd" "\n")
  (read-char "(press any key)")
  (decode-coding-region (point-min) (point-max) 'euc-jp-dos)
  (read-char "doesn't delete all of the character '^M'. (press any key)")
  (set-buffer-multibyte t))
========================================================================

I made a patch to fix the problem. Please check it.

----Next_Part(Sun_Dec_20_17_57_09_2009_140)--
Content-Type: Text/X-Patch; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="coding.c__decode_eol.diff"

--- coding.c.orig	2009-07-08 12:09:16.000000000 +0900
+++ coding.c	2009-12-20 16:36:45.887121600 +0900
@@ -6598,7 +6598,8 @@
 	{
 	  int pos_byte = coding->dst_pos_byte;
 	  int pos = coding->dst_pos;
-	  int pos_end = pos + coding->produced_char - 1;
+	  int pos_end = pos + (coding->dst_multibyte
+			       ? coding->produced_char : coding->produced) - 1;
 
 	  while (pos < pos_end)
 	    {

----Next_Part(Sun_Dec_20_17_57_09_2009_140)----