Re: libnettle/libhogweed WIP

[Ted Zlatanov <tzz@lifelogs.com>]

On Wed, 19 Apr 2017 08:22:10 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> I see the confusion. Yes, I want to allow multibyte input. Users
>> shouldn't have to jump through hoops to use these functions.

SM> FWIW, I disagree.  You should check that either the string is unibyte
SM> (AKA byte_size<0) or that it's ASCII-only (byte_size==size).

SM> Forcing your users to (de|en)code explicitly before calling your
SM> functions isn't making them jump through hoops: it's helping them have
SM> the correct mental model of what "multibyte text" means.

I think inside the Emacs environment, users won't care too much about
the coding system or byte count, they'll just expect strings and buffers
to work. But you're right that for interoperability with other tools and
for file interactions, this is not trivial. And internally, I see it
can't be assumed that the decrypted text will have the same coding
system and unibyte/multibyte state as the original (this wasn't an issue
with `secure-hash' since it only does digests).

Since `secure-hash' supports multibyte in strings and buffers I think it
makes sense to be consistent, and that's why I factored out
extract_data_from_object(). So if we decide to make a change for how
multibyte text is treated, let's do that consistently, thinking about
interoperability and files, and consider the output as well. I think it
will require a payload structure. What do you think?

Ted