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 12:32:32 +0300 Message-ID: <8337daggnj.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1492248739 2694 195.159.176.226 (15 Apr 2017 09:32:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 15 Apr 2017 09:32:19 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 15 11:32:15 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 1czK3z-0000YD-2i for ged-emacs-devel@m.gmane.org; Sat, 15 Apr 2017 11:32:15 +0200 Original-Received: from localhost ([::1]:56011 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1czK43-0000qv-6c for ged-emacs-devel@m.gmane.org; Sat, 15 Apr 2017 05:32:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44801) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1czK3u-0000qi-SM for emacs-devel@gnu.org; Sat, 15 Apr 2017 05:32:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1czK3r-0007L0-Oi for emacs-devel@gnu.org; Sat, 15 Apr 2017 05:32:10 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43160) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1czK3r-0007Ku-LX for emacs-devel@gnu.org; Sat, 15 Apr 2017 05:32:07 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4276 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1czK3p-0004mq-Mq for emacs-devel@gnu.org; Sat, 15 Apr 2017 05:32:06 -0400 In-reply-to: <87wpamww9k.fsf@lifelogs.com> (message from Ted Zlatanov on Fri, 14 Apr 2017 16:48:39 -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:213972 Archived-At: > 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(). I'm not sure I understand what you say here. In particular, I see no s.size in gnutls_symmetric_aead. What did I miss? I do see some issues in gnutls_symmetric_aead with how you create Lisp strings. You first correctly call make_uninit_string, which gives you a unibyte string with no contents. Then you populate that string's data by calling gnutls_aead_cipher_encrypt resp. decrypt functions. But then you call make_unibyte_string with the resulting data, which is redundant: you already have the unibyte string with the correct data in the 'storage' variable. So you should just return 'storage', like you do in, e.g., gnutls_symmetric. I see your methods are still strings, whereas I suggested making them symbols. Any reasons why you didn't? A minor nit: in doc strings, please always leave 2 spaces between sentences, not 1. In gnutls-ciphers, is it known in advance that all cipher names are pure-ASCII? If not, I'd advise against using make_unibyte_string there, as Lisp data structures returned to Lisp programs should not include unibyte non-ASCII strings unless strictly necessary. Likewise in gnutls-macs and in gnutls-digests. (Of course, if methods become symbols, this will become a moot point.) > 1) how about a special C data structure that has to be called to get its > payload data, but can't be inspected or printed otherwise, and after N > reads is inaccessible? Would that be resistant to Lisp-level attempts to > grab the data? Only data structures defined via DEFVAR are accessible to Lisp, so keeping the data in C and providing accessors for Lisp programs will achieve the result, I think. The accessor could wipe the data after N accesses. > 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? Why not simply pass nil as the input, with the meaning that it stands for the current buffer's text? Or, better yet, pass START and END to allow a substring of current buffer's text. We do that in a lot of places (for different reasons, of course). IOW, I see no reason to involve the Lisp interpreter for this job. Am I missing something? Thanks.