--- Begin Message ---
|
Subject: |
bug#5251: 23.1; problem in decode_eol of coding.c |
|
Date: |
Sun, 20 Dec 2009 17:57:09 +0900 |
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.
--- 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)
{
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#5251: 23.1; problem in decode_eol of coding.c |
|
Date: |
Wed, 17 Feb 2016 17:53:41 +0200 |
> From: Andrew Hyatt <address@hidden>
> Date: Tue, 16 Feb 2016 22:41:32 -0500
> Cc: address@hidden
>
>
> 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.
--- End Message ---