Re: [PATCH] GnuTLS support on Woe32

[Ted Zlatanov]

On Tue, 3 May 2011 04:27:55 +0200 Juanma Barranquero <address@hidden> wrote: 

JB> 2011/5/2 Ted Zlatanov <address@hidden>:
>> So we just need to modify `emacs_gnutls_global_init' to load and check
>> the GnuTLS library

JB> emacs_gnutls_global_init is called too late, after
JB> gnutls_global_set_log_function and gnutls_global_set_log_level have
JB> been called. I've chosen to call Fgnutls_available_p at the start of
JB> Fgnutls_boot.

OK.

JB> Please take a look at the attached patch, which is a rough cut; it
JB> lacks any documentation (no ChangeLog entries) and I'm not really sure
JB> what am I doing with the errors :-)  Also, I haven't added GNUTLS_LOG
JB> calls; feel free to suggest them as appropriate.

It seems like we have to keep the list of imported functions up to date
and remember to always use the fn_NAME version.  Is there a way to
automate that with a macro like CALL_GNUTLS_FUNCTION(NAME, args) or with
a .h file?  The way you have it is pretty easy to forget and it's hard
to grep for it.

JB> +  Lisp_Object found = Fassq (Qgnutls_dll, Vlibrary_cache);
JB> +  if (CONSP (found))
JB> +    return XCDR (found);
JB> +  else
JB> +    {
JB> +      Lisp_Object status;
JB> +      status = init_gnutls_functions (Vdynamic_library_alist) ? Qt : Qnil;
JB> +      Vlibrary_cache = Fcons (Fcons (Qgnutls_dll, status), Vlibrary_cache);
JB> +      return status;
JB> +    }

Can `found' ever be true but not a cons?  Should we redo the
initialization in that case?

The else block above should log things at level 1, I think, since it's a
rare event and important to know:

CHECK_STRING (Qgnutls_dll);
GNUTLS_LOG2 (1, max_log_level, "loading the GnuTLS DLL: ", SSDATA 
(Qgnutls_dll));

Otherwise it looks OK to me, though I don't know the W32 side at all so
I can't comment on the w32.* changes.

Ted