2007/10/23, Daniel Stenberg wrote:

> Does those headers define something that we can #ifdef on to check for an
> existing socklen_t typedef?

Fortunately yes. It seems that those versions of ws2tcpip.h files that
do define socklen_t also define INET_ADDRSTRLEN, and when socklen_t
definition is missing also INET_ADDRSTRLEN is missing.

So the actual check is quite easy, unless someone points out a version
of ws2tcpip.h that does not behave as described above.

> > Since
> > http://cool.haxx.se/cvs.cgi/curl/include/curl/curl.h.diff?r1=1.327&r2=1.328
> > the interface of the library requires socklen_t being already defined since
> > it is exposing struct curl_sockaddr.
> >
> > So the real question when using msvc is if libcurl should stop providing a
> > socklen_t replacement or otherwise also provide it in inlude/curl/curl.h if
> > not available for Windows target builds.
>
> I think the latter, as I can't see how we can do the first without breaking
> the build on some msvc compiles. Or did I missunderstand?

What I actually was asking was that, if a specific version of a
compiler from a specific vendor didn't define socklen_t but that
vendor did supply a "patch / service pack / PSDK /
whatever_name_the_vendor_feels_calling_it" that 'fixed' the compiler
providing the socklen_t definition, besides numerous other fixes,
should we support the unpatched compiler or the patched one.

I suppose the proper answer is 'if it can be done support both', after
all we try to be real portable ;-)

Tomorrow I'll make some compilation tests taking in account
INET_ADDRSTRLEN before providing a patch.

-- 
-=[Yang]=-