Re: libnettle/libhogweed WIP

[Ted Zlatanov <tzz@lifelogs.com>]

On Wed, 19 Apr 2017 18:45:40 +0300 Eli Zaretskii <eliz@gnu.org> 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 <tzz@lifelogs.com> 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 <larsi@gnus.org> wrote: 

LI> Ted Zlatanov <tzz@lifelogs.com> 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