[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);
with
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
#+end_src
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
Ted
- Re: libnettle/libhogweed WIP, Ted Zlatanov, 2017/04/11
- Re: libnettle/libhogweed WIP, Ted Zlatanov, 2017/04/14
- Re: libnettle/libhogweed WIP, Eli Zaretskii, 2017/04/15
- Re: libnettle/libhogweed WIP, Ted Zlatanov, 2017/04/15
- Re: libnettle/libhogweed WIP, Eli Zaretskii, 2017/04/15
- Re: libnettle/libhogweed WIP,
Ted Zlatanov <=
- Re: libnettle/libhogweed WIP, Eli Zaretskii, 2017/04/16
- Re: libnettle/libhogweed WIP, Eli Zaretskii, 2017/04/16
- Re: libnettle/libhogweed WIP, Ted Zlatanov, 2017/04/17
- Re: libnettle/libhogweed WIP, Eli Zaretskii, 2017/04/17
- Re: libnettle/libhogweed WIP, Ted Zlatanov, 2017/04/17
- Re: libnettle/libhogweed WIP, Eli Zaretskii, 2017/04/17
- Re: libnettle/libhogweed WIP, Ted Zlatanov, 2017/04/17
- Re: libnettle/libhogweed WIP, Eli Zaretskii, 2017/04/17
- Re: libnettle/libhogweed WIP, Ted Zlatanov, 2017/04/17
- Re: libnettle/libhogweed WIP, Ted Zlatanov, 2017/04/17