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
