bug#50560: 28.0.50; 'insert-file-contents-literally' on multibyte buffers

[Augusto Stoffel]

On Mon, 13 Sep 2021 at 09:10, Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Augusto Stoffel <arstoffel@gmail.com> writes:
>
>> I thought 'insert-file-contents-literally' literally just inserted the
>> file contents, as bytes, but I noticed that in the following code
>>
>>     (create-image
>>      (with-temp-buffer
>>        (set-buffer-multibyte nil)
>>        (insert-file-contents-literally "picure.jpg")
>>        (buffer-substring-no-properties (point-min) (point-max)))
>>      nil t)
>>
>> the call to 'set-buffer-multibyte' is really essential.
>
> In what way?  If the first byte in a binary file is #xff, inserting the
> file literally in a buffer and saying `(following-char)' on the first
> character in the buffer will say #xff.
>
> But, yes, when dealing with octet streams, it's a lot less confusing if
> you're using unibyte buffers (and strings).
>
>> Is this intended?  If so, I think a note in the doctring is due.
>
> The doc string doesn't say anything about bytes, so I think that's an
> interpretation on your side.
>
> `insert-file-contents-literally' does insert "literally" -- but the byte
> contents of the internal buffer structure can't be violated (emacs uses
> utf-8 (plus extensions) for multibyte buffers).

Ah, sure, there is no coding _conversion_, but the bytes are still
interpreted according to the buffer's coding system.

I guess that's obvious in hindsight.  Still, reading the bytes from a
file is slightly trickier than it might seem, so there could be a word
of caution somewhere.