Hi there,

INTRODUCTION:
-------------

First part involved in the HP-UX socklen_t issue...

HP-UX's sys/socket.h has the following socklen_t data type definition:

typedef size_t socklen_t;

So, socklen_t width depends on the data model being used at compile
time, 64-Bit wide under LP64 and 32-Bit wide under the ILP32 data
model.

Additionally, socklen_t data type definition is always available in
sys/socket.h and independent of the _XOPEN_SOURCE_EXTENDED
preprocessor symbol definition.

Second part involved in the HP-UX socklen_t issue...

Some structures and functions have/use different definitions depending
on the _XOPEN_SOURCE_EXTENDED preprocessor symbol definition.

For example, getpeername(2) and getsockopt(2) have following prototypes:

#if defined(_XOPEN_SOURCE_EXTENDED)
int getpeername(
    int s,
    struct sockaddr *addr,
    socklen_t *addrlen
    );
#else
int getpeername(
    int s,
    void *addr,
    int *addrlen
    );
#endif

#if defined(_XOPEN_SOURCE_EXTENDED)
int getsockopt(
    int s,
    int level,
    int optname,
    void *optval,
    socklen_t *optlen
    );
#else
int getsockopt(
    int s,
    int level,
    int optname,
    void *optval,
    int *optlen
    );
#endif

It is obvious that if the actual size of the addrlen parameter passed
using a pointer when calling getpeername() is different than the size
of the addrlen argument expected and received using a pointer by
getpeername() funny things could happen.

Same thing happens with getsockopt() and the optlen parameter/argument
which is used to return data from the function to the calling program.

So, when would the actual size mismatch really happen?

If libcurl defines a variable with data type socklen_t for addrlen or
optlen and libcurl is compiled without _XOPEN_SOURCE_EXTENDED defined
using the LP64 data model.

If libcurl defines a variable with data type int for addrlen or optlen
and libcurl is compiled with _XOPEN_SOURCE_EXTENDED defined using the
LP64 data model.

In other cases it seems that there will be no actual data size
mismatch. But if the compiler warns on mismatched size assignments.
the compiler is right.

CURRENT STATE:
--------------

The configure script finds out if socklen_t exists as a data type, and
provides a valid replacement in config.h in case that socklen_t does
not exist. Most non-configure systems use config-platform.h to define
a socklen_t replacement if required.

For HP-UX, the above check results in always finding a socklen_t data
type, even when it should not be used in some cases to directly
interface some functions as previously described.

In order to mitigate all this issue, setup_once.h defines some HP-UX
specific function wrappers for getsockname(), getsockopt(), accept()
and recvfrom().

But the problem of mismatched socklen_t data types still exists for
data structures which use this data type.

HP-UX compiler warning level has just been raised to better expose the
issue on the daily autobuilds. This will trigger more than a thousand
warnings mostly related with this issue and other 64/32-Bit
portability problems.

PROPOSAL:
---------

Change configure script to actually detect the data type that libcurl
should be using internally for variables whose 'normal' data type
would be socklen_t. The check would be nearly the same than the one
which is now used to find a socklen_t equivalent, but first checking
for socklen_t. This would allow to define a symbol named
'curl_socklen_t' which would have the proper data type to use in all
cases.

Adjust config-platform.h specific files to also define 'curl_socklen_t'.

Replace all 'socklen_t' literals in libcurl with 'curl_socklen_t'.

Remove HP-UX specific wrapper functions from setup_once.h

Verify that the number of warnings in HP-UX daily builds has decreased
and that no further problems have been introduced.

I do not foresee any need to expose 'curl_socklen_t' in the external
API. So, I think that this change should have no drawbacks.

-- 
-=[Yang]=-