curl_easy_getinfo with CURLINFO_TLS_SSL_PTR not able to get compiled

[gnanagurun]

I did this

curl_easy_getinfo with CURLINFO_TLS_SSL_PTR gives compilation error - "call to '_curl_easy_getinfo_err_curl_slist' declared with attribute warning: curl_easy_getinfo expects a pointer to 'struct curl_slist *' for this info". I just passing the address of this variable struct curl_tlssessioninfo tls_ssl" to curl_easy_getinfo. To solve this compilation issue, i have tried to replace this with "struct curl_slist". Able to compile with this change but while running it gives segmentation fault even there is NULL checking in my code.

I expected the following

curl/libcurl version

libcurl version: 7.52.1 / OpenSSL version: 1.1.0d
[curl -V output]

operating system

Centos 6.5

[jay]

It looks like it has to do with the gcc typechecking. Since CURLINFO_TLS_SSL_PTR is internally treated categorized as slist type that may be why. But then if this is a problem I'm a little bit puzzled why nobody has ever reported it before.

The type should be struct curl_tlssessioninfo not struct curl_slist, What do you mean you tried to replace and what is segfaulting? Can you show the code?

[gnanagurun]

Below is the code snippet
// struct curl_tlssessioninfo *tls_ssl = NULL; commented out due to compilation issue
struct curl_slist *tls_ssl = NULL;
curl_easy_getinfo(curl_handle, CURLINFO_TLS_SSL_PTR, &tls_ssl);
if (tls_ssl && tls_ssl->data) // NULL checking
{
printf("tls_ssl ->data = %s\n", tls_ssl->data); // --> This is the place where segfault occur
}

Please let me know how to resolve the compilation issue when use "struct curl_tlssessioninfo"

[jzakrzewski]

I don't think that tls_ssl->data is a NULL-terminated string. I'd guess that printf simply reads too much because of that and this is the cause of the segfault.

[gnanagurun]

This cannot be the cause of segfault. Even it occur if i just access the first character of tls_ssl->data[0]. It seems the type should be struct curl_tlssessioninfo. How to solve the compilation issue?

[bagder]

See #1525 for my suggested fix.