"Daniel Stenberg" <dan...@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
