From: Ted Zlatanov <tzz@lifelogs.com>
To: emacs-devel@gnu.org
Subject: Re: libnettle/libhogweed WIP
Date: Sat, 15 Apr 2017 10:27:33 -0400 [thread overview]
Message-ID: <87d1cdwxt6.fsf@lifelogs.com> (raw)
In-Reply-To: 8337daggnj.fsf@gnu.org
On Sat, 15 Apr 2017 12:32:32 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Ted Zlatanov <tzz@lifelogs.com>
>> Date: Fri, 14 Apr 2017 16:48:39 -0400
>>
TZ> * TODO from Eli: avoid allocating a scratch buffer and then copying its
TZ> data (inside make_unibyte_string) into a newly-allocated string.
TZ> Instead, use make_uninit_string.
>>
>> I've done this as much as possible. For AEAD output, I'm not sure how to
>> set the length of an already-allocated string; I didn't want to modify
>> `s.size' directly. I didn't see a function or macro to do it. This is
>> needed for gnutls_symmetric_aead().
EZ> I'm not sure I understand what you say here. In particular, I see no
EZ> s.size in gnutls_symmetric_aead. What did I miss?
EZ> I do see some issues in gnutls_symmetric_aead with how you create Lisp
EZ> strings. You first correctly call make_uninit_string, which gives you
EZ> a unibyte string with no contents. Then you populate that string's
EZ> data by calling gnutls_aead_cipher_encrypt resp. decrypt functions.
EZ> But then you call make_unibyte_string with the resulting data, which
EZ> is redundant: you already have the unibyte string with the correct
EZ> data in the 'storage' variable. So you should just return 'storage',
EZ> like you do in, e.g., gnutls_symmetric.
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 see your methods are still strings, whereas I suggested making them
EZ> symbols. Any reasons why you didn't?
Forgot :) Done now.
EZ> A minor nit: in doc strings, please always leave 2 spaces between
EZ> sentences, not 1.
That was the auto reformat. Fixed, thanks.
EZ> Only data structures defined via DEFVAR are accessible to Lisp, so
EZ> keeping the data in C and providing accessors for Lisp programs will
EZ> achieve the result, I think. The accessor could wipe the data after N
EZ> accesses.
OK, I'll work on that later.
>> 2) Could there be a built-in C way to let C core functions take strings,
>> but callers can invoke them with '(buffer-string) to tell *the core
>> function* to call that form. In other words, I want the eval to be done
>> at the C level, so that looking at the call tree won't reveal the actual
>> string that was passed to the function. I think that would simplify my
>> code and other C code too. I can probably fake it with eval()? WDYT?
EZ> Why not simply pass nil as the input, with the meaning that it stands
EZ> for the current buffer's text? Or, better yet, pass START and END to
EZ> allow a substring of current buffer's text. We do that in a lot of
EZ> places (for different reasons, of course).
EZ> IOW, I see no reason to involve the Lisp interpreter for this job. Am
EZ> I missing something?
We're assuming that there's only three ways to pass data to the
function, and they can all be expressed in the parameters instead of
code: buffer-string, buffer-substring, and direct string. I think there
may be other use cases, but maybe I'm wrong? Streaming data, event
handlers, and coding system adjustments maybe?
This is not standardized for core C functions AFAIK; I don't want to
rewrite the first 150 lines of secure_hash() and extend them when I need
to support more ways to pass data. So I think this should be provided by
the core somehow, in a way that can be reused. I thought of the
following possibilities:
a) Could the core C functions use the `interactive' spec? That may be the
best way, but I don't know of any core C functions that use it.
b) Another way is to write a special core C function to interpret these
special parameters and give back text. I could start writing this
function with the first 150 lines of secure_hash() and then try to
standardize the parameters.
c) my earlier idea, to eval a form in the core C function, but that's
slow and awkward. It *could* be a little better for performance, if the
C function doesn't call the form when it's not needed. And it's very
flexible.
Ted
next prev parent reply other threads:[~2017-04-15 14:27 UTC|newest]
Thread overview: 128+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-20 10:00 How to ship native modules? Elias Mårtenson
2017-02-20 15:27 ` Eli Zaretskii
2017-02-20 16:01 ` Elias Mårtenson
2017-02-20 16:30 ` Eli Zaretskii
2017-02-21 2:48 ` Elias Mårtenson
2017-02-21 3:41 ` Eli Zaretskii
2017-02-21 4:13 ` Elias Mårtenson
2017-02-21 16:48 ` Eli Zaretskii
2017-02-21 20:06 ` John Wiegley
2017-02-21 14:44 ` Stefan Monnier
[not found] ` <CADtN0WLjNcFRLCsJNZX+XfqOcq+veTaoGkwHQCV9bjvuQoEORA@mail.gmail.com>
2017-02-21 15:48 ` Elias Mårtenson
2017-02-21 17:14 ` Stefan Monnier
2017-02-21 16:59 ` Eli Zaretskii
2017-03-02 14:59 ` request to reconsider libnettle/libhogweed (was: How to ship native modules?) Ted Zlatanov
2017-03-02 15:19 ` request to reconsider libnettle/libhogweed Stefan Monnier
2017-03-02 15:55 ` request to reconsider libnettle/libhogweed (was: How to ship native modules?) Eli Zaretskii
2017-03-15 21:19 ` libnettle/libhogweed WIP (was: request to reconsider libnettle/libhogweed) Ted Zlatanov
2017-03-16 15:28 ` Eli Zaretskii
2017-03-17 22:46 ` libnettle/libhogweed WIP Ted Zlatanov
2017-03-18 8:12 ` Eli Zaretskii
2017-03-20 18:45 ` Ted Zlatanov
2017-04-11 20:05 ` Ted Zlatanov
2017-04-14 20:48 ` Ted Zlatanov
2017-04-15 9:32 ` Eli Zaretskii
2017-04-15 14:27 ` Ted Zlatanov [this message]
2017-04-15 14:55 ` Eli Zaretskii
2017-04-16 2:39 ` Ted Zlatanov
2017-04-16 6:25 ` Eli Zaretskii
2017-04-16 6:51 ` Eli Zaretskii
2017-04-17 16:23 ` Ted Zlatanov
2017-04-17 16:34 ` Eli Zaretskii
2017-04-17 16:55 ` Ted Zlatanov
2017-04-17 17:11 ` Eli Zaretskii
2017-04-17 17:34 ` Ted Zlatanov
2017-04-17 17:46 ` Ted Zlatanov
2017-04-17 18:11 ` Eli Zaretskii
2017-04-17 20:50 ` Ted Zlatanov
2017-04-17 21:19 ` Noam Postavsky
2017-04-17 23:29 ` Ted Zlatanov
2017-04-19 2:08 ` Ted Zlatanov
2017-04-19 2:42 ` Noam Postavsky
2017-04-19 15:24 ` Davis Herring
2017-04-19 15:45 ` Eli Zaretskii
2017-04-20 17:24 ` Ted Zlatanov
2017-04-20 19:38 ` Eli Zaretskii
2017-04-20 20:24 ` Ted Zlatanov
2017-04-20 20:42 ` Lars Ingebrigtsen
2017-04-20 21:54 ` Ted Zlatanov
2017-04-21 6:21 ` Eli Zaretskii
2017-04-21 18:45 ` Lars Ingebrigtsen
2017-04-21 19:15 ` Eli Zaretskii
2017-04-21 6:14 ` Eli Zaretskii
2017-05-15 21:55 ` Ted Zlatanov
2017-05-16 22:19 ` Ted Zlatanov
2017-05-17 16:22 ` Eli Zaretskii
2017-05-17 20:05 ` Ted Zlatanov
2017-05-31 18:17 ` Ted Zlatanov
2017-06-03 7:23 ` Eli Zaretskii
2017-06-03 9:00 ` Andreas Schwab
2017-06-03 10:01 ` Eli Zaretskii
2017-06-03 10:09 ` Andreas Schwab
2017-06-03 10:47 ` Eli Zaretskii
2017-06-27 22:58 ` Ted Zlatanov
2017-06-28 16:54 ` Eli Zaretskii
2017-06-28 19:44 ` Ted Zlatanov
2017-07-13 18:35 ` Ted Zlatanov
2017-07-14 15:10 ` Ted Zlatanov
2017-07-14 19:04 ` Eli Zaretskii
2017-07-14 19:43 ` Ted Zlatanov
2017-07-14 20:04 ` Eli Zaretskii
2017-07-15 18:30 ` Ted Zlatanov
2017-07-15 9:15 ` Eli Zaretskii
2017-07-15 18:40 ` Ted Zlatanov
2017-07-15 19:12 ` Eli Zaretskii
2017-07-22 9:10 ` Eli Zaretskii
2017-07-26 6:58 ` Ted Zlatanov
2017-07-26 14:52 ` Eli Zaretskii
2017-07-26 15:34 ` Ted Zlatanov
2017-07-26 15:49 ` Eli Zaretskii
2017-07-26 16:08 ` Ted Zlatanov
2017-07-26 18:51 ` Eli Zaretskii
2017-07-26 20:48 ` Ted Zlatanov
2017-07-27 0:19 ` Paul Eggert
2017-07-27 2:34 ` Eli Zaretskii
2017-07-27 4:36 ` Paul Eggert
2017-07-27 15:56 ` Ted Zlatanov
2017-08-03 19:52 ` Ted Zlatanov
2017-08-03 8:02 ` Paul Eggert
2017-08-03 16:49 ` Eli Zaretskii
2017-04-18 17:44 ` Ted Zlatanov
2017-04-19 12:22 ` Stefan Monnier
2017-04-19 13:38 ` Ted Zlatanov
2017-04-19 14:16 ` Lars Ingebrigtsen
2017-04-19 14:48 ` Stefan Monnier
2017-04-19 14:41 ` Eli Zaretskii
2017-04-19 14:54 ` Stefan Monnier
2017-04-19 15:31 ` Eli Zaretskii
2017-04-19 15:48 ` Ted Zlatanov
2017-04-19 16:49 ` Lars Ingebrigtsen
2017-04-19 17:24 ` Eli Zaretskii
2017-04-19 19:53 ` Stefan Monnier
2017-04-20 2:30 ` Eli Zaretskii
2017-04-20 3:36 ` Stefan Monnier
2017-04-20 15:46 ` Eli Zaretskii
2017-04-20 15:59 ` Lars Ingebrigtsen
2017-04-20 16:24 ` Eli Zaretskii
2017-04-20 17:25 ` Stefan Monnier
2017-04-20 19:40 ` Lars Ingebrigtsen
2017-04-20 20:31 ` Eli Zaretskii
2017-04-20 19:58 ` Eli Zaretskii
2017-04-20 20:36 ` Eli Zaretskii
2017-04-20 17:14 ` Stefan Monnier
2017-04-20 19:29 ` Eli Zaretskii
2017-04-19 19:49 ` Stefan Monnier
2017-04-17 16:00 ` rename STRING_SET_CHARS to STRING_SET_SIZE (was: libnettle/libhogweed WIP) Ted Zlatanov
2017-04-17 16:24 ` rename STRING_SET_CHARS to STRING_SET_SIZE Eli Zaretskii
2017-04-17 16:29 ` Stefan Monnier
2017-04-17 16:34 ` Ted Zlatanov
2017-04-16 3:37 ` libnettle/libhogweed WIP Stefan Monnier
2017-04-16 6:19 ` Eli Zaretskii
2017-04-16 13:20 ` Stefan Monnier
2017-04-16 7:47 ` Toon Claes
2017-03-02 17:58 ` request to reconsider libnettle/libhogweed Paul Eggert
2017-03-02 18:33 ` Ted Zlatanov
2017-02-20 15:33 ` How to ship native modules? Aurélien Aptel
2017-02-21 4:50 ` Andreas Politz
2017-02-21 5:12 ` Elias Mårtenson
2017-02-21 5:23 ` Andreas Politz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d1cdwxt6.fsf@lifelogs.com \
--to=tzz@lifelogs.com \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).