bug#44411: 28.0.50; uudecode-decode-region-internal is broken

[Eli Zaretskii <eliz@gnu.org>]

> 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.