Daniel,

> Personally, I don't understand what this new check will do that the previous
> didn't. But I guess a few rounds in the autobuilds will tell...

In fact CURL_CHECK_TYPE_SOCKLEN_T was created only to keep around
TYPE_SOCKLEN_T while the new one was given a few rounds in the
autobuilds.

Once that all glitches with CURL_CHECK_TYPE_SOCKLEN_T have been sorted
out, it can be renamed to TYPE_SOCKLEN_T or it can keep the new name
and then delete TYPE_SOCKLEN_T. Which do you prefer ?

It is true that the recent incarnation provides little added value. We
will get a failure at configuration step, instead of a runtime bug, in
case some platform has mixed types for the argument whose type would
be socklen_t in getpeername, getsockname, bind and accept. This kind
of strange failure wouldn't be detected previously.

So with the new version, failure to find a socklen_t replacement can
mean that a new equivalent check has to be done or that the type for
the argument whose type would be socklen_t is not uniform among the
declarations of those four functions.

Obviously, platforms that don't have neither of this two problems
should not notice any change with the recent version.

The other minor 'feature' is the ability to check and search for an
equivalent for those platforms that have windows headers and autoconf
capabilities.

-=[Yang]=-
Received on 2005-12-16