On Thu, 24 Oct 2013, Christian Grothoff wrote:
struct curl_tlsinfo tlsinfo;
union {
struct curl_tlsinfo *tlsinfo;
struct curl_slist *to_slist;
} gptr;
memset (&tlsinfo, 0, sizeof (tlsinfo));
gptr.tlsinfo = &tlsinfo;
curl_easy_getinfo (curl,
CURLINFO_TLS_SESSION,
&gptr);
As you can see, I'm passing a pointer to gptr, which itself contains a
pointer to the tlsinfo. Hence ultimately what is being passed is a pointer
to the pointer. This was done to comply with the 'struct curl_slist *'
paradigm which was used in other places of the code.
Oh.
But that looks horrible from a user's perspective and opens up for lots of
mistakes.
I think we should instead do one of these:
1) add a new type that would return a pointer to an object where the object
would be option-specific. So in this case it'd return a pointer to a
curl_tlsinfo struct (and that struct would need to be kept in the curl easy
handle).
/* it would look like this */
struct curl_tlsinfo *tlsinfop;
curl_easy_getinfo(curl,
CURLINFO_TLS_SESSION,
&tlsinfop);
2) add a new type that would pass in a pointer to a struct where that struct
is object specific, and libcurl would write the return-data into that struct.
That would make the application "own" the memory that is written to.
/* it would look like this */
struct curl_tlsinfo tlsinfo;
curl_easy_getinfo(curl,
CURLINFO_TLS_SESSION,
&tlsinfo);
Opinions?
--
/ daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
