cURL / Mailing Lists / curl-library / Single Mail


Re: Missing 'state.os_err'

From: Daniel Stenberg <>
Date: Thu, 8 May 2014 08:52:09 +0200 (CEST)

On Thu, 27 Mar 2014, Gisle Vanem wrote:

(picking up an old thread that slipped through the cracks)

> 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?

> An oversight or what?

Well, maybe. :-)

I would say that in all cases where we use errno in libcurl to check for
success or failure, if we then fail we should store errno in
data->state.os_errno. Does that sound reasonable?

That of course leads to the question: in your example case where WSAStartup()
fails, is that really an errno that is returned? I would probably lean towards
a no...

> 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", \
> where 'return CURLE_NOT_BUILT_IN' is normally used.

At least on some places where we return CURLE_NOT_BUILT_IN we could also add a
failf() to specify what it is that isn't built-in but grepping the code for
that code shows a number of places where it isn't that easily done.

> 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.

Logging really is a bit of a tricky thing. Too little, too much, how to
control etc.

We sort of have one more level and that's the output that gets enabled in
debug builds, usually controlled with the DEBUGF() macro. But that requires a
rebuild and is probably not what you had in mind.

Would "another log level" really solve these quirks and problems you ran into

List admin:
Received on 2014-05-08