2010/4/30, Tanguy Fautre wrote:

> All the newly defined posix constants are located in errno.h, located between line
> 91 and 132.
>
> /* POSIX SUPPLEMENT */
> #define EADDRINUSE 100
> [...]
> #define EWOULDBLOCK 140

How nice. I assume that you are saying that all of the above are
unconditionally defined in errno.h. Please confirm this or show which
preprocessor statement makes them visible.

> Here are the lines of setup_once.h that conflicts with these constants (from line 365
> to 417). I've marked the conflicting lines with a C (hopefully, I've not missed any).

Well, I hope you test the proposed fix. So if something is still
missing, it won't go unnoticed.

> Don't hesitate if you need me to try an updated version of setup_once.h.

Sure. But, most probably, I won't be able to provide something for
testing before monday.

Just stick around reading http://curl.haxx.se/mail/etiquette.html meanwhile.

2010/4/30, Daniel Stenberg wrote:

> Why on earth do they define all these errno values when there's nothing
> in winsock that uses them?

Who knows (raising my shoulders).

Winsock errors must be retrieved using WSAGetLastError() function (our
SOCKERRNO macro), while errors generated by most CRT functions must be
retrieved using GetLastError() function (our ERRNO macro).

> It seems we have to (for VS2010 builds) #undef all errno defines we use
> and #define them ourselves unconditionally to their WSA* equivalents.
> Don't you guys agree?

I have not yet looked into this for each affected macro. But it
depends mostly on how we are fetching the error code in our own code.
As a general rule, error codes from errno.h should prevail for CRT
errors and should be fetched with our ERRNO macro, while error codes
from winsock.h or winsock2.h should prevail for winsock function
errors that should be retrieved with our SOCKERRNO macro.

> The current setup_once.h seems to allow the compiler's errno.h values
> to have precedence over our own definitions, do we need to keep that
> or can we just #undef + #define all errnos independently of VS version?

No. Depending on each macro, and for which function we use it one will
prevail over the other. But not in an absolutely general case that
makes one set always prevail over the other.

I'll try hard to find some free time this weekend to provide a patch
that Tanguy can test.

-- 
-=[Yang]=-
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html