Re: libnettle/libhogweed WIP

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 21 Apr 2017 20:45:58 +0200
> 
> If I understand the code correctly (and I may definitely not be doing
> that; I've just skimmed it very, very briefly), you may be able to point
> the encryption code at the Emacs buffer contents directly without
> copying it anywhere beforehand, and then (since the results are usually
> of very similar length) back to the same Emacs buffer afterwards.
> 
> 4GB Emacs buffer -> encrypted to 4GB GnuTLS buffer -> 4GB Emacs buffer

But since (AFAIU) the size of the encrypted text is not always known
in advance, the encryption might be significantly slower than just
reading in the original file, because of the need to enlarge the gap
(and thus reallocate text) several times.  Similar things happen when
you visit a compressed file, which triggers its on-the-fly
decompression.

> (with-temp-buffer
>   (set-buffer-multibyte nil)  <<<<<<<<<<<<<<< this is not needed
>   (let ((coding-system-for-read 'binary)
>         (coding-system-for-write 'binary))
>     (unwind-protect
>       (progn
>        (insert-file-contents "My DVD.iso")
>        (gnutls-encrypt ... ... (current-buffer))
>        (write-region ...))
>      (clear-buffer (current-buffer))))) ;; New function that runs memset
>                                         ;; over the buffer area
>     
> Or something.  We have to look at what buffers write-region creates and
> stuff, but in the 'binary case, I don't think it creates copies of the
> Emacs buffer anywhere.

The data will always leave traces, because doing the above involves
reallocation of memory, so you are likely to leave traces in the page
file and in memory.  But I don't think you can avoid that, whatever
you do: as long as data needs to be read into memory to process it, it
will always leave traces.