Re: libnettle/libhogweed WIP

[Eli Zaretskii]

> 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().

I'm not sure I understand what you say here.  In particular, I see no
s.size in gnutls_symmetric_aead.  What did I miss?

I do see some issues in gnutls_symmetric_aead with how you create Lisp
strings.  You first correctly call make_uninit_string, which gives you
a unibyte string with no contents.  Then you populate that string's
data by calling gnutls_aead_cipher_encrypt resp. decrypt functions.
But then you call make_unibyte_string with the resulting data, which
is redundant: you already have the unibyte string with the correct
data in the 'storage' variable.  So you should just return 'storage',
like you do in, e.g., gnutls_symmetric.

I see your methods are still strings, whereas I suggested making them
symbols.  Any reasons why you didn't?

A minor nit: in doc strings, please always leave 2 spaces between
sentences, not 1.

In gnutls-ciphers, is it known in advance that all cipher names are
pure-ASCII?  If not, I'd advise against using make_unibyte_string
there, as Lisp data structures returned to Lisp programs should not
include unibyte non-ASCII strings unless strictly necessary.  Likewise
in gnutls-macs and in gnutls-digests.  (Of course, if methods become
symbols, this will become a moot point.)

> 1) how about a special C data structure that has to be called to get its
> payload data, but can't be inspected or printed otherwise, and after N
> reads is inaccessible? Would that be resistant to Lisp-level attempts to
> grab the data?

Only data structures defined via DEFVAR are accessible to Lisp, so
keeping the data in C and providing accessors for Lisp programs will
achieve the result, I think.  The accessor could wipe the data after N
accesses.

> 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?

Why not simply pass nil as the input, with the meaning that it stands
for the current buffer's text?  Or, better yet, pass START and END to
allow a substring of current buffer's text.  We do that in a lot of
places (for different reasons, of course).

IOW, I see no reason to involve the Lisp interpreter for this job.  Am
I missing something?

Thanks.