From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: libnettle/libhogweed WIP Date: Thu, 20 Apr 2017 13:24:50 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87r30nq9el.fsf@lifelogs.com> 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> <834lxndmd9.fsf@gnu.org> <87efwrug6z.fsf@lifelogs.com> <87r30qu5av.fsf@lifelogs.com> <874lxmtxyy.fsf@lifelogs.com> <87r30prvwt.fsf@lifelogs.com> <8337d4csez.fsf@gnu.org> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1492709185 9865 195.159.176.226 (20 Apr 2017 17:26:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 20 Apr 2017 17:26:25 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 20 19:26:22 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 1d1FqX-0002St-KY for ged-emacs-devel@m.gmane.org; Thu, 20 Apr 2017 19:26:21 +0200 Original-Received: from localhost ([::1]:55228 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d1Fqd-0004Y6-GX for ged-emacs-devel@m.gmane.org; Thu, 20 Apr 2017 13:26:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57664) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d1FpL-0003qT-PK for emacs-devel@gnu.org; Thu, 20 Apr 2017 13:25:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d1FpH-0001sT-QM for emacs-devel@gnu.org; Thu, 20 Apr 2017 13:25:07 -0400 Original-Received: from [195.159.176.226] (port=51573 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1d1FpH-0001s6-Jj for emacs-devel@gnu.org; Thu, 20 Apr 2017 13:25:03 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1d1Fp9-0000Zp-Ou for emacs-devel@gnu.org; Thu, 20 Apr 2017 19:24:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 81 Original-X-Complaints-To: usenet@blaine.gmane.org X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never Cancel-Lock: sha1:5KHnjbTB6XcNhCqueDt6sBHbjF8= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 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:214152 Archived-At: On Wed, 19 Apr 2017 18:45:40 +0300 Eli Zaretskii wrote: EZ> The NEWS entry should mention the section in the manual which EZ> describes these features. I think I did it right? That NEWS format is really confusing. EZ> Also, you consistently leave only one space between sentences, which EZ> is not our convention. Hrm, yeah, and I have my paragraph reformat set to use two spaces. Weird. I'll try to watch for it but maybe it can also be a dir-locals setting in the docs directory? Sorry in any case. EZ> I would suggest to extract the common description of the EZ> (BUFFER-OR-STRING START END CODING-SYSTEM NOERROR) form, so you could EZ> have it only once, instead of repeating it with each function. I'm not sure how to make that look good in the texi docs. Is there an existing convention for defining a data format that will be reused in function definitions? It would be handy if I could refer to it from the C function docs too. I think it would be generally useful for the C core and Lisp functions, so it's worth making it look nice. Finally, I'd like a similar format for output as well, since writing the output to a buffer or a file is a very common need. EZ> I think (file "FOO") is the best. (I understand that the file will be EZ> submitted to GnuTLS functions for processing, is that right?) Since you and David agreed, I've made that the third allowed format. It errors out for now. Should I use an internal buffer (not in the visible list) and read into it, and then use the buffer data? Or should I use emacs_open() etc. and actually implement a raw file read operation, which should be a bit more secure and less subject to coding systems? NP> On Tue, Apr 18, 2017 at 10:08 PM, Ted Zlatanov wrote: >> >> * I pin to GnuTLS 3.4.0 instead of AC_CHECK_FUNCS_ONCE because I >> couldn't get that autoconf macro to work! I would appreciate some help >> for how to use that macro for GnuTLS API functions. I think it needs >> to be told to include "gnutls/crypto.h" because the resulting C test >> doesn't. NP> Missing header would only be a warning. I guess what's actually NP> missing is the -lgnutls in $LIBS. Possibly you must use AC_CHECK_FUNCS NP> instead of AC_CHECK_FUNCS_ONCE since you need to manipulate $LIBS NP> around the call. I tried that and a dozen other macros and ideas, and couldn't get any of itto work. The headers were not getting included. I hate autoconf and gave up for now. On Wed, 19 Apr 2017 18:49:56 +0200 Lars Ingebrigtsen wrote: LI> Ted Zlatanov writes: >> Not allow them where? Just the new stuff I'm adding? Or also >> `secure-hash' and `md5' etc? Or anything that deals with crypto (which >> could also affect EPG)? LI> I was thinking just the new stuff you're adding, because the ship has LI> sailed for the older functions. (I'd expect the older functions to LI> become obsolete after a while...) OK, understood. So I'd only allow (BUFFER-OR-STRING-OR-FILE START-BYTE END-BYTE NOERROR), and I'd error out if the buffer or string have multibyte data. Since Eli and Stefan are still discussing this, I'll hold off making the change, but it looks like the consensus is to only do unibyte. LI> I think in the base64 case, it's led to confusion over the years. I think you're right. The (file "filename") input/output format spec should make the coding system issues less important, since users won't have to read the file into a string or buffer in order to operate on it. Ted