Re: libnettle/libhogweed WIP

[Ted Zlatanov]

On Mon, 17 Apr 2017 19:34:10 +0300 Eli Zaretskii <address@hidden> wrote: 

EZ> Because you already require unibyte text as input.  Unibyte text
EZ> doesn't need encoding, it's either ASCII or was already encoded before
EZ> calling these functions.
...
EZ> If you want to allow multibyte input that needs to be encoded as part
EZ> of these functions, then yes.

I see the confusion. Yes, I want to allow multibyte input. Users
shouldn't have to jump through hoops to use these functions.

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.

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

I don't see the difference between allocating a C string +
make_unibyte_string(), and doing

  Lisp_Object storage = make_uninit_string (storage_length);
  ...
  return make_unibyte_string (SSDATA (storage), storage_length);

because either way the data has to be copied, and the latter needs less
care with freeing the memory. It's really not a big deal to switch to
your suggestion, I just don't know why it matters?

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

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

Perfect, thanks.

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

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

Understood, I'll use clear-string and worry less :) Thank you again.

Ted