GNU bug report logs - #50560
28.0.50; 'insert-file-contents-literally' on multibyte buffers

Previous Next

Full log

View this message in rfc822 format

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Augusto Stoffel <arstoffel <at> gmail.com>
Cc: 50560 <at> debbugs.gnu.org
Subject: bug#50560: 28.0.50; 'insert-file-contents-literally' on multibyte buffers
Date: Mon, 13 Sep 2021 09:10:59 +0200

Augusto Stoffel <arstoffel <at> 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).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.