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: Mon, 17 Apr 2017 19:34:10 +0300 Message-ID: <834lxndmd9.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> <83tw5pg1q3.fsf@gnu.org> <87zifhulc2.fsf@lifelogs.com> <83h91og80k.fsf@gnu.org> <87pogbuhoe.fsf@lifelogs.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1492446829 5766 195.159.176.226 (17 Apr 2017 16:33:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 17 Apr 2017 16:33:49 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 17 18:33:45 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 1d09ay-0001Of-GS for ged-emacs-devel@m.gmane.org; Mon, 17 Apr 2017 18:33:44 +0200 Original-Received: from localhost ([::1]:37763 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d09b4-0006Y1-6R for ged-emacs-devel@m.gmane.org; Mon, 17 Apr 2017 12:33:50 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54438) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d09av-0006Xv-9V for emacs-devel@gnu.org; Mon, 17 Apr 2017 12:33:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d09as-0001md-6t for emacs-devel@gnu.org; Mon, 17 Apr 2017 12:33:41 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47810) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d09as-0001mU-3P for emacs-devel@gnu.org; Mon, 17 Apr 2017 12:33:38 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1772 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1d09ar-0006aC-Db for emacs-devel@gnu.org; Mon, 17 Apr 2017 12:33:37 -0400 In-reply-to: <87pogbuhoe.fsf@lifelogs.com> (message from Ted Zlatanov on Mon, 17 Apr 2017 12:23:29 -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:214074 Archived-At: > From: Ted Zlatanov > Date: Mon, 17 Apr 2017 12:23:29 -0400 > > On Sun, 16 Apr 2017 09:25:13 +0300 Eli Zaretskii wrote: > > >> Like I said, the first 150 lines of secure_hash() demonstrate the > >> complexity. > > EZ> Most of that is encoding the text, which is not relevant to your > EZ> functions. What's left is about 10 lines for a string and 30 for a > EZ> buffer substring, not too much IMO. > > Why do you think the new functions don't need it? Because you already require unibyte text as input. Unibyte text doesn't need encoding, it's either ASCII or was already encoded before calling these functions. > Either way I'll pull the code out into a shared function, but right now > my patch assumes the input is always unibyte and in a Lisp string, and > the return is always binary. secure_hash() does much better on both > input and output, respecting coding systems and multibyte strings, and > can produce binary or hex-encoded output. So I think all of that > extra code is useful. If you want to allow multibyte input that needs to be encoded as part of these functions, then yes. > SM> I think we don't have the function that Ted wants. Basically, we'd > SM> need to provide a `resize_string_data` function > > That seems pretty complicated. I'll leave the patch as is, doing an > extra copy, and add a TODO referencing this potential function. Why not use my suggestion, producing a Lisp string out of C string just before returning? > Somewhat related--is there a sure way to wipe Lisp strings in C? I've done > > memset(SSDATA (storage), 0, storage_length); I think you want clear-string, a.k.a. Fclear_string (although it does almost exactly what you did). > Does the core allow C functions to say "GC this Lisp object right > away and make sure it's wiped" or some subset of that? No. And you are aware that GC doesn't wipe memory, only reshuffles it and marks it free, yes? So clearing the contents is required anyway, and after that, why do you care when it will be GC'ed?