[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#44411: 28.0.50; uudecode-decode-region-internal is broken
From: |
Eli Zaretskii |
Subject: |
bug#44411: 28.0.50; uudecode-decode-region-internal is broken |
Date: |
Wed, 04 Nov 2020 17:26:52 +0200 |
> Date: Wed, 04 Nov 2020 17:26:56 +0900
> From: Kazuhiro Ito <kzhr@d1.dion.ne.jp>
> Cc: 44411@debbugs.gnu.org
>
> > What do you mean by "decode eight-bit characters"?
>
> I mean "decode uuencoded raw bytes 128-255 as eight-bit characters".
>
> > How could such "characters" appear in uuencoded email message?
>
> I did not said anything about uuencoded email message. What do you
> mean?
Sorry, it looks like I misunderstood the use case. Ignore that
question.
> 1. Yank below uuencoded string into multibyte buffer.
>
> begin 644 c8c8c8c8.bin
> $R,C(R```@
> ``
> end
> size 4
>
> 2. C-SPC at the beginning of uuencoded text and move point to the end
> of uuencoded text.
>
> 3. M-x uudecode-decode-region-internal
>
> 4. decoded result is broken. Original data is 4bytes of 0xc8, but
> inserted text is "8888". uudecode-decode-region-external returns
> expected result.
OK, I see the problem now: it's the call to decode-coding-string,
which replaced string-as-unibyte of yore.
> > Please show only the changes to fix what you think is a bug.
>
> Here is.
OK, I agree also to your other optimizations, but can we please go a
step further and avoid consing a string here? 'insert' is perfectly
capable of inserting characters, not only strings. So in the
unibyte-buffer case, just something like
(apply #'insert (nreverse result))
with 'result' being a list of bytes, will produce what you want. And
in the multibyte-buffer case you just need to convert each byte to its
Unicode-compatible codepoint, by using
(decode-char 'eight-bit CH)
probably in 'mapcar' or somesuch, and then call 'insert'.
Can you augment your patch along these lines, please?
Thanks.