From: Eli Zaretskii <eliz@gnu.org>
To: emacs-devel@gnu.org
Subject: Re: libnettle/libhogweed WIP
Date: Sat, 15 Apr 2017 17:55:00 +0300 [thread overview]
Message-ID: <83tw5pg1q3.fsf@gnu.org> (raw)
In-Reply-To: <87d1cdwxt6.fsf@lifelogs.com> (message from Ted Zlatanov on Sat, 15 Apr 2017 10:27:33 -0400)
> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Sat, 15 Apr 2017 10:27:33 -0400
>
> 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.
I think STRING_SET_CHARS is what you want here.
> >> 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?
What other types of text except strings and buffer text are there? I
think there are no others, and all the other features are necessarily
built on top of those two.
> 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.
I don't think I see the problem; can you give an example?
Buffer text is just a C string (with the slight complication of the
gap), so I don't understand why you'd need to rewrite code that much.
> 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.
These seem to be complications for which I see no justifications for
now.
next prev parent reply other threads:[~2017-04-15 14:55 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
2017-04-15 14:55 ` Eli Zaretskii [this message]
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=83tw5pg1q3.fsf@gnu.org \
--to=eliz@gnu.org \
--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).