Re: libnettle/libhogweed WIP

[Eli Zaretskii]

> From: Ted Zlatanov <address@hidden>
> Date: Sat, 15 Apr 2017 10:27:33 -0400
> 
> On Sat, 15 Apr 2017 12:32:32 +0300 Eli Zaretskii <address@hidden> wrote: 
> 
> >> From: Ted Zlatanov <address@hidden>
> >> Date: Fri, 14 Apr 2017 16:48:39 -0400
> >> 
> TZ> * TODO from Eli: avoid allocating a scratch buffer and then copying its
> TZ> data (inside make_unibyte_string) into a newly-allocated string.
> TZ> Instead, use make_uninit_string.
> >> 
> >> I've done this as much as possible. For AEAD output, I'm not sure how to
> >> set the length of an already-allocated string; I didn't want to modify
> >> `s.size' directly. I didn't see a function or macro to do it. This is
> >> needed for gnutls_symmetric_aead().
> 
> EZ> I'm not sure I understand what you say here.  In particular, I see no
> EZ> s.size in gnutls_symmetric_aead.  What did I miss?
> 
> EZ> I do see some issues in gnutls_symmetric_aead with how you create Lisp
> EZ> strings.  You first correctly call make_uninit_string, which gives you
> EZ> a unibyte string with no contents.  Then you populate that string's
> EZ> data by calling gnutls_aead_cipher_encrypt resp. decrypt functions.
> EZ> But then you call make_unibyte_string with the resulting data, which
> EZ> is redundant: you already have the unibyte string with the correct
> EZ> data in the 'storage' variable.  So you should just return 'storage',
> EZ> like you do in, e.g., gnutls_symmetric.
> 
> These two comments are related: for example, the decryption with
> CAMELLIA-256-GCM produces less bytes of output that the input. But I
> don't want to try to anticipate that byte count--it complicates the code
> needlessly. So instead I want to cut the Lisp string `storage' to
> `storage_length' bytes after gnutls_aead_cipher_{encrypt,decrypt}()
> modifies `storage_length'. I can't find a macro or function to do it, so
> I used make_unibyte_string() for now and am asking how to do it better.

I think STRING_SET_CHARS is what you want here.

> >> 2) Could there be a built-in C way to let C core functions take strings,
> >> but callers can invoke them with '(buffer-string) to tell *the core
> >> function* to call that form. In other words, I want the eval to be done
> >> at the C level, so that looking at the call tree won't reveal the actual
> >> string that was passed to the function. I think that would simplify my
> >> code and other C code too. I can probably fake it with eval()? WDYT?
> 
> EZ> Why not simply pass nil as the input, with the meaning that it stands
> EZ> for the current buffer's text?  Or, better yet, pass START and END to
> EZ> allow a substring of current buffer's text.  We do that in a lot of
> EZ> places (for different reasons, of course).
> 
> EZ> IOW, I see no reason to involve the Lisp interpreter for this job.  Am
> EZ> I missing something?
> 
> We're assuming that there's only three ways to pass data to the
> function, and they can all be expressed in the parameters instead of
> code: buffer-string, buffer-substring, and direct string. I think there
> may be other use cases, but maybe I'm wrong? Streaming data, event
> handlers, and coding system adjustments maybe?

What other types of text except strings and buffer text are there?  I
think there are no others, and all the other features are necessarily
built on top of those two.

> This is not standardized for core C functions AFAIK; I don't want to
> rewrite the first 150 lines of secure_hash() and extend them when I need
> to support more ways to pass data.

I don't think I see the problem; can you give an example?

Buffer text is just a C string (with the slight complication of the
gap), so I don't understand why you'd need to rewrite code that much.

> a) Could the core C functions use the `interactive' spec? That may be the
> best way, but I don't know of any core C functions that use it.
> 
> b) Another way is to write a special core C function to interpret these
> special parameters and give back text. I could start writing this
> function with the first 150 lines of secure_hash() and then try to
> standardize the parameters.
> 
> c) my earlier idea, to eval a form in the core C function, but that's
> slow and awkward. It *could* be a little better for performance, if the
> C function doesn't call the form when it's not needed. And it's very
> flexible.

These seem to be complications for which I see no justifications for
now.