Ticket History #2116: getsockname argument handling

Our configure script tries to work out the types of the arguments to
getsockname and getpeername.

1) It completely fails to figure out argument 3 (pointer to length) on
Solaris in normal 64-bit mode, because without the XPG-enabling
macros defined, the only system-provided declaration uses "void *".

Possibly we should turn those macros on (specifically,
-D_XOPEN_SOURCE=500 to get the SUSv2 declarations, and
-D__EXTENSIONS__ to re-enable SVR4 extensions) for Solaris. Greg
Hudson and I have disagreed on this point over Zephyr. I'm still
not fully convinced one way or the other. Sam agreed with Greg.

2) If the configure scripts can't work it out, the corresponding
macros aren't defined, so each source file using them has to test
for that and specify defaults. The defaults differ. Each of
"size_t", "int", and "unsigned int" is used in multiple places.

The defaults should be consistent, and implemented in aclocal.m4.

3) Using "size_t" is wrong, and on 64-bit Solaris breaks things.

The default probably should be "socklen_t", unless there's a
platform where socklen_t exists, *and* socklen_t* isn't right for
getsockname, *and* the configure script can't figure out the
correct type.

In our current nightly testing configurations, it appears that
Tru64 5.1A, IRIX 6.5.7, and OS X 10.2 are the configurations where
we don't find a socklen_t type we can use, and in each of those
cases, the configure script does successfully determine the types
to use for getsockname.

4) Testing for getpeername independently is probably a waste of
cycles. I'd be very surprised if there's any platform anywhere
that uses different types for getsockname and getpeername.

Ken