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