Re: base64-decode-region inserts carriage-returns

[Eli Zaretskii]

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.