[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libnettle/libhogweed WIP

From: Stefan Monnier
Subject: Re: libnettle/libhogweed WIP
Date: Wed, 19 Apr 2017 15:49:47 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

> That is, I think
> (md5 (encode-coding-string "Héllo" 'iso-8859-1))
> is a better interface than
> (md5 "Héllo" nil nil 'iso-8859-1)

That's right.

> Yes, but as Eli and Stefan said, perhaps there's something to be said
> for just allowing encrypting the internal representation of Emacs
> objects, too.  (Which is what base64-encode-string/base64-encode-region
> does.)
> This is more flexible, but is this a flexibility that's useful?

This is useful for purposes like "check that the hash of a buffer is not
affected by an operation".  Where encoding would be more costly than
computing the hash and would bring no benefit (unless you specifically
want to ignore changes to the buffer which are not visible in the
encoded output).

> I think in the base64 case, it's led to confusion over the years.

I agree that for base64-encode-*, this optimisation doesn't make much
sense (when would you want to do (base64-encode (encoding-coding-string
FOO 'emacs-internal)) ?) so it only leads to bugs.
I think it was not a conscious choice but just an oversight in
the implementation.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]