[Top][All Lists]

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

Re: libnettle/libhogweed WIP

From: Ted Zlatanov
Subject: Re: libnettle/libhogweed WIP
Date: Sat, 15 Apr 2017 22:39:57 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

On Sat, 15 Apr 2017 17:55:00 +0300 Eli Zaretskii <address@hidden> wrote: 

>> From: Ted Zlatanov <address@hidden>
>> Date: Sat, 15 Apr 2017 10:27:33 -0400
>> 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.

EZ> I think STRING_SET_CHARS is what you want here.

Thank you for letting me know. That macro has a terrible name and should
probably be called STRING_SET_{SIZE,LENGTH} or similar. But yeah, it
seems right.

When I replace gnutls.c:1828

    return make_unibyte_string (SSDATA (storage), storage_length);


    STRING_SET_CHARS (storage, storage_length);
    return storage;

I get a segfault running the tests:

#+begin_src text
Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
compact_small_strings () at alloc.c:2227
2227                  nbytes = s ? STRING_BYTES (s) : SDATA_NBYTES (from);
[gdb]> bt
#0  compact_small_strings () at alloc.c:2227
#1  sweep_strings () at alloc.c:2159
#2  0x00000000005542d4 in gc_sweep () at alloc.c:7088
#3  garbage_collect_1 (end=<optimized out>) at alloc.c:5965
#4  Fgarbage_collect () at alloc.c:6096
#5  0x000000000056b1ef in maybe_gc () at lisp.h:4667
#6  eval_sub (form=0x14ef193) at eval.c:2128
[gdb]> p s
$1 = (struct Lisp_String *) 0x2020202020202020
[gdb]> p *s
Cannot access memory at address 0x2020202020202020


It happens during the tests with 100% certainty but I'm not sure what
test or string specifically caused it.

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

Like I said, the first 150 lines of secure_hash() demonstrate the
complexity. I'll just pull them out into a common function and use that,
and assume you're right that only buffer extraction and direct strings
are needed, and that the other ideas I had were not so good.

Thanks for your help

reply via email to

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