To: krb5-bugs@mit.edu
Subject: getsockname argument handling
From: Ken Raeburn <raeburn@MIT.EDU>
Date: Tue, 13 Jan 2004 15:52:04 -0500
Message-Id: <tx14quz1si3.fsf@mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 1748

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