RE: CURLINFO_GNUTLS_SESSION (was Re: Patch: Support CURLINFO_CERTINFO with GnuTLS)
Date: Tue, 19 Nov 2013 00:42:49 +0000
On Mon, 18 Nov 2013, Christian Grothoff wrote:
> > Exactly - neither one is great but I feel option 2 is the lesser of
> > two evils so to speak.
> Well, my first patch had the application own the memory.
> Daniel didn't like that idea as too error-prone. So go figure.
I'll have a look at your original patch tomorrow, to see if we are talking
about the same thing, but I thought (off the top of head) that option 2 that
Daniel mentioned was different to your original implementation.
> > Excuse my ignorance here (sorry) but I got slightly confused with
> > your point there - could you please elaborate?
> By declaring the type as "void *" instead of "gnutls_session_t", I can
> avoid having to #include <gnutls.h>", which might be inappropriate
> if curl is linked against OpenSSL. Imagine I defined
> Then you could ONLY #include that struct in your C code if you before
> also included the headers for openssl, gnutls and NSS.
Yes I see your point now ;-) I certainly wouldn't recommending #including
all those backend #include files - yuk!
> Yes, we could do the union thing, but I don't see a way to keep
> this simple and build nicely given that the types for the members
> of the union would be scattered over the various SSL backend
> #include files, and we can hardly include them all.
True. I guess the ssl_connect_data struct doesn't have this problem as it
#ifdef's the ones it needs based on the build - but with an API function you
don't really have that capability unless...
> Including only the "available" subset would mean patching the curl.h
> header depending on the build system and introduce binary
> compatibility issues simply because the C compiler might choose a
> different layout for the union depending on which of the conditionally
> defined members happen to be around.
...and that's another can of worms :(
> So yes, you can do this, but are you fully aware of all of the possible
> consequences if you did this? I considered it, and figured 'void *'
> was simple enough to use in practice.
It wasn't that obvious from your patch or from what information I had read
in previous messages in the thread - I did mention that I was late coming
into this ;-)
> > Thanks for your efforts so far and sorry if I have made things
> > more complicated ;-)
> No problem.
Thank you for taking the time to provide the extra explanation - it is much
appreciated. I certainly helps me understand your patch more and the reasons
for doing things the way you have ;-)
As I mentioned above I will take a look at your original patch tomorrow -
mainly to see if I have got my wires crossed / misunderstood Daniel's point
about the application owned memory.
List admin: http://cool.haxx.se/list/listinfo/curl-library
Received on 2013-11-19