Re: libnettle/libhogweed WIP

[Ted Zlatanov]

On Sun, 16 Apr 2017 09:25:13 +0300 Eli Zaretskii <address@hidden> wrote: 

>> From: Ted Zlatanov <address@hidden>
>> Date: Sat, 15 Apr 2017 22:39:57 -0400
>> 
>> Like I said, the first 150 lines of secure_hash() demonstrate the
>> complexity.

EZ> Most of that is encoding the text, which is not relevant to your
EZ> functions.  What's left is about 10 lines for a string and 30 for a
EZ> buffer substring, not too much IMO.

Why do you think the new functions don't need it?

Either way I'll pull the code out into a shared function, but right now
my patch assumes the input is always unibyte and in a Lisp string, and
the return is always binary. secure_hash() does much better on both
input and output, respecting coding systems and multibyte strings, and
can produce binary or hex-encoded output. So I think all of that
extra code is useful.

On Sat, 15 Apr 2017 23:37:57 -0400 Stefan Monnier <address@hidden> wrote: 

SM> I think we don't have the function that Ted wants. Basically, we'd
SM> need to provide a `resize_string_data` function

That seems pretty complicated. I'll leave the patch as is, doing an
extra copy, and add a TODO referencing this potential function.

Somewhat related--is there a sure way to wipe Lisp strings in C? I've done

    memset(SSDATA (storage), 0, storage_length);

but maybe that's not ideal. Does the core allow C functions to say "GC
this Lisp object right away and make sure it's wiped" or some subset of
that?

Thanks
Ted