On 10/27/2013 01:36 PM, Daniel Stenberg wrote:
> 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?

I personally think (1) is cleaner. I've attached a patch that implements
your version (1) against current Git.

Happy hacking!

Christian

Received on 2013-11-17