cURL / Mailing Lists / curl-library / Single Mail

curl-library

Missing 'state.os_err'

From: Gisle Vanem <gvanem_at_yahoo.no>
Date: Thu, 27 Mar 2014 21:52:08 +0100

I note that 'data->state.os_errno' is not set in many places. Only some
places around send(), bind() etc. What if 'curl_easy_getinfo (..CURLINFO_OS_ERRNO..)'
is called to retrieve the OS-error when thing fails?

I do note the man-page says "connect failure". But things can fail before a
connect() is called. No? Like in telnet.c; shouldn't it be stored like this:

@@ -217,6 +217,7 @@
   /* should always succeed. But, just in case... */
   if(err != 0) {
     failf(data,"WSAStartup failed (%d)",err);
+ data->state.os_errno = err;
     return CURLE_FAILED_INIT;
   }

@@ -230,6 +231,7 @@
       /* Our version isn't supported */
       failf(data,"insufficient winsock version to support "
             "telnet");
+ data->state.os_errno = WSAVERNOTSUPPORTED;
       return CURLE_FAILED_INIT;
   }

-----

An oversight or what?

Btw. there are other places where libcurl's very strict error-messages are
not very helpful. Like when I tried to build with '-DUSE_LWIPSOCK' on Win32,
(not to mention all the define-combos that can mess things up) I got the dreaded
curl message "A requested feature, protocol or option was not found .." w/o
knowing what I did wrong. It would be very helpful to know where and why I got
it. So I ended up with a temporary hack of using:

  #define NOT_BUILT_IN() \
           printf("Returning 'CURLE_NOT_BUILT_IN' at %s(%u)\n", \
               __FILE__, __LINE__), CURLE_NOT_BUILT_IN

where 'return CURLE_NOT_BUILT_IN' is normally used.

That helped greatly. Using a debugger with a conditional break-point would
be an option, but I wish libcurl had some more verbose trace in cases
like this. Independent of 'CURLOPT_VERBOSE' which in many cases are
too late or too limited.

--gv
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-03-27