From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: Re: base64-decode-region inserts carriage-returns Date: Sun, 9 Jun 2002 12:13:45 +0300 (IDT) Sender: bug-gnu-emacs-admin@gnu.org Message-ID: References: <87u1od7b99.fsf@blarg.net> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: main.gmane.org 1023614303 24549 127.0.0.1 (9 Jun 2002 09:18:23 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 9 Jun 2002 09:18:23 +0000 (UTC) Cc: bug-gnu-emacs@gnu.org Return-path: Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17Gyq6-0006Nq-00 for ; Sun, 09 Jun 2002 11:18:23 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17Gypr-0000NG-00; Sun, 09 Jun 2002 05:18:07 -0400 Original-Received: from is.elta.co.il ([199.203.121.2]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17Gync-0000Hu-00 for ; Sun, 09 Jun 2002 05:15:48 -0400 Original-Received: from is (is [199.203.121.2]) by is.elta.co.il (8.9.3/8.8.8) with SMTP id MAA15107; Sun, 9 Jun 2002 12:13:46 +0300 (IDT) X-Sender: eliz@is Original-To: Eric Hanchrow In-Reply-To: <87u1od7b99.fsf@blarg.net> Errors-To: bug-gnu-emacs-admin@gnu.org X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Bug reports for GNU Emacs, the Swiss army knife of text editors List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.bugs:1899 X-Report-Spam: http://spam.gmane.org/gmane.emacs.bugs:1899 On 8 Jun 2002, Eric Hanchrow wrote: > Save the decoded version to a different file for comparison with the > original: > > C-x C-w bin.again RET > > Now examine the newly-saved version with od back at the shell: > > od -c /tmp/bin.again > > you'll now see 0000000 001 002 003 \r \n 001 002 003 \r \n > > Thus the binary file has had some carriage-returns inserted into it, This happens because the buffer where you performed the conversion has undecided-dos as the value of its buffer-file-coding-system variable. > which is a Bad Thing, since those carriage-returns were not present in > the encoded data. I'm not sure your conclusion is right. base64-decode-region is a primitive which acts on a region. It doesn't have any clue about what does the caller want to do with the result of decoding, and it is IMHO wrong to change buffer-file-coding-system because something you did with a portion of buffer's text. For example, imagine that some program source sent as a base64-encoded attachment is being decoded on a Windows system. In that case, I think there's nothing wrong with saving the result with DOS EOLs; users might even expect that. More generally, the way the buffer should be saved is something a user or higher-level features should determine. That is, it is up to the caller of base64-decode-region to decide whether or not to change the way buffer is encoded when written Primitives that operate on a region should not change that. I'd say that a user-friendly interface to base64-decode-region should decode the text in a scratch buffer, and the insert the result into the user buffer. That way, the value of buffer-file-coding-system in the scratch buffer doesn't count, and encoding of the user buffer is not affected by a primitive.