emacs-devel
[Top][All Lists]
Advanced

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

Re: libnettle/libhogweed WIP


From: Eli Zaretskii
Subject: Re: libnettle/libhogweed WIP
Date: Mon, 17 Apr 2017 19:34:10 +0300

> From: Ted Zlatanov <address@hidden>
> Date: Mon, 17 Apr 2017 12:23:29 -0400
> 
> On Sun, 16 Apr 2017 09:25:13 +0300 Eli Zaretskii <address@hidden> wrote: 
> 
> >> 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?

Because you already require unibyte text as input.  Unibyte text
doesn't need encoding, it's either ASCII or was already encoded before
calling these functions.

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

If you want to allow multibyte input that needs to be encoded as part
of these functions, then yes.

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

Why not use my suggestion, producing a Lisp string out of C string
just before returning?

> Somewhat related--is there a sure way to wipe Lisp strings in C? I've done
> 
>     memset(SSDATA (storage), 0, storage_length);

I think you want clear-string, a.k.a. Fclear_string (although it does
almost exactly what you did).

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

No.  And you are aware that GC doesn't wipe memory, only reshuffles it
and marks it free, yes?  So clearing the contents is required anyway,
and after that, why do you care when it will be GC'ed?



reply via email to

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