Subject: bug#52670: closed (Re: bug#52670: [PATCH] legacy base64 encoding of latin-1)

From: [email-masked] (GNU bug Tracking System)
Date: Mon, 20 Dec 2021 19:25:03 +0000

Your bug report

#52670: legacy base64 encoding of latin-1

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

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

Subject: Re: bug#52670: [PATCH] legacy base64 encoding of latin-1
From: Mattias Engdegård <[email-masked]>
To: Eli Zaretskii <[email-masked]>
Cc: [email-masked]
Date: Mon, 20 Dec 2021 20:24:21 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

20 dec. 2021 kl. 20:10 skrev Eli Zaretskii <[email-masked]>:

> Thanks, but this should at the very least be announced as an
> incompatible Lisp change in NEWS.

Right, I added a detailed notice. Thanks for taking a look!

Pushed; closing.

Subject: legacy base64 encoding of latin-1
From: [email-masked]
To: [email-masked]
Date: Sun, 19 Dec 2021 22:47:15 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

For what appears to be historical reasons, the base64 encoding functions (base64-encode-string etc) treat characters in the range U+0080..U+00FF as if they were raw bytes in the 127..255 range. This means that

  (base64-encode-string "ÿ")

and

  (base64-encode-string "\xff")

return the same result although the strings are completely different. Attempts to encode other multibyte characters fail (correctly). For example,

  (base64-encode-string "Ÿ")

signals an error, as expected.

I propose we tighten up the behavior by eliminating the legacy handling of characters in the  U+0080..U+00FF range. Letting the bug stay in place enables incorrect, brittle and error-prone usage: the functions are clearly intended to be fed encoded text only and should signal an error when not, as stated in the manual.