From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: libnettle/libhogweed WIP Date: Sat, 15 Apr 2017 17:55:00 +0300 Message-ID: <83tw5pg1q3.fsf@gnu.org> References: <83a89gq3us.fsf@gnu.org> <87bmtjiv0w.fsf_-_@lifelogs.com> <83o9xjn06c.fsf@gnu.org> <87shmeb5ln.fsf_-_@lifelogs.com> <83y3w5z1ez.fsf@gnu.org> <87lgr6yakj.fsf@lifelogs.com> <87wpamww9k.fsf@lifelogs.com> <8337daggnj.fsf@gnu.org> <87d1cdwxt6.fsf@lifelogs.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1492268128 14419 195.159.176.226 (15 Apr 2017 14:55:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 15 Apr 2017 14:55:28 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 15 16:55:23 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1czP6e-0003TS-FA for ged-emacs-devel@m.gmane.org; Sat, 15 Apr 2017 16:55:20 +0200 Original-Received: from localhost ([::1]:57066 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1czP6h-0005bM-9C for ged-emacs-devel@m.gmane.org; Sat, 15 Apr 2017 10:55:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43244) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1czP5x-0005Zo-3X for emacs-devel@gnu.org; Sat, 15 Apr 2017 10:54:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1czP5t-0000E4-R6 for emacs-devel@gnu.org; Sat, 15 Apr 2017 10:54:36 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45878) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1czP5t-0000Dt-NO for emacs-devel@gnu.org; Sat, 15 Apr 2017 10:54:33 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1563 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1czP5t-0005uU-1X for emacs-devel@gnu.org; Sat, 15 Apr 2017 10:54:33 -0400 In-reply-to: <87d1cdwxt6.fsf@lifelogs.com> (message from Ted Zlatanov on Sat, 15 Apr 2017 10:27:33 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:213976 Archived-At: > From: Ted Zlatanov > Date: Sat, 15 Apr 2017 10:27:33 -0400 > > On Sat, 15 Apr 2017 12:32:32 +0300 Eli Zaretskii wrote: > > >> From: Ted Zlatanov > >> 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.