emacs-devel
[Top][All Lists]
Advanced

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

Re: libnettle/libhogweed WIP


From: Ted Zlatanov
Subject: Re: libnettle/libhogweed WIP
Date: Wed, 19 Apr 2017 11:48:10 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

On Wed, 19 Apr 2017 10:54:55 -0400 Stefan Monnier <address@hidden> wrote: 

On Wed, 19 Apr 2017 17:41:52 +0300 Eli Zaretskii <address@hidden> wrote: 

>> I think it's important to discuss the expected results, because we
>> could avoid encoding the string, either inside or outside of the
>> functions, and just use its bytes instead, disregarding their
>> interpretation as characters.  The question is: would that yield what
>> users will want and expect?  The answer could be YES in some use cases
>> and NO in others.

SM> Indeed, in some cases we might want to work on multibyte text without
SM> encoding it at all.  Maybe we could have an argument specifying that the
SM> caller intends to operate on the internal encoding.

SM> But what shouldn't be in those functions is encoding/decoding: if
SM> encoding/decoding is needed, then it should be done before/after calling
SM> the functions.

That's exactly what's happening, except it's done in C code, by
extract_data_from_object() before the function is called. So I can make
it a requirement. But I think there's two distinct use cases:
"Emacs to Emacs buffer/string" and "Emacs to non-Emacs file/string" and
maybe they should be considered separately.

Eli wrote:
>> But if we pass buffer text, we could always encode using
>> buffer-file-coding-system, and IMO that would be the expected result
>> (provided that the user didn't want to use the internal
>> representation).  We do this in the likes of write-region, so why not
>> here?

Right, I think user expectations are important here.

Lars wrote:
>> The less confusion in this area the better, and especially for
>> encryption functions where you really want to get the correct text back
>> again, I think it would be better, long-term, to not allow non-unibyte
>> text inputs.

Not allow them where? Just the new stuff I'm adding? Or also
`secure-hash' and `md5' etc? Or anything that deals with crypto (which
could also affect EPG)?

If it's just the code in my patch, let me know what I need to change in
the way it calls extract_data_from_object() and I'll adjust the code,
the tests, and the docs. IIUC Stefan wants the call to fail if the
string or buffer is mulibyte and Lars agreed?

But we can also look to define a payload structure that would express
the coding system, unibyte/multibyte, etc. better.

Ted




reply via email to

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