"Daniel Stenberg" <daniel_at_haxx.se> wrote:

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

Yes, this OS-error (or errno) could be useful to the caller.

> That of course leads to the question: in your example case where WSAStartup()
> fails, is that really an errno that is returned?

WSAStartup() returns != 0 for failures. It's the closest thing to an 'errno'in
this case. It should be preserved too IMHO.

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

I'm okay with a rebuild. What I had in mind was some "maintainer debug".
Since there seems too many debug-combos already [1], I'm not sure how.
Maybe an env-var '$LIBCURL_DEBUG=level/mask' and code to enable this
only in one #define. E.g. 'DCURLDEBUG'. The rest controlled by level or a
bit-mask.

[1] Currently I've noted all these in libcurl+curl:
-DDEBUG
-DCURLDEBUG
-DDEBUG_ADDRINFO
-DDEBUGBUILD
 -DCURL_MT_MALLOC_FILL, -DCURL_MT_FREE_FILL
-DCURL_LIBSSH2_DEBUG
-DDEBUG_LDAP
-DDEBUG_CONFIG
-DDPRINTF_DEBUG2
-DGTLSDEBUG

Have I missed some? It's not clear from the sources what difference
there are in e.g. 'CURLDEBUG' and DEBUGBUILD'.

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