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

[cut]

> 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.

Mmmm...

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.

Cheers again

Steve
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-11-19