Re: bin/48063: incorrect definition of socklen_t

[David Holland <dholland-bugs%netbsd.org@localhost>]

The following reply was made to PR bin/48063; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: Christos Zoulas <christos%netbsd.org@localhost>
Subject: Re: bin/48063: incorrect definition of socklen_t
Date: Sat, 20 Jul 2013 06:12:49 +0000

 On Fri, Jul 19, 2013 at 07:55:01AM +0000, Justin Cormack wrote:
  >  http://pubs.opengroup.org/onlinepubs/7908799/xns/syssocket.h.html
  >  
  >  "<sys/socket.h> makes available a type, socklen_t, which is an
  >  unsigned opaque integral type of length of at least 32 bits"
 
 That's not really relevant.
 
 socklen_t is the type of the pointer-to-length argument of accept(),
 getsockname(), getpeername(), and getsockopt(). When defining it for
 compat, it needs to match the host system's declarations of these
 functions, or code that calls these functions using socklen_t won't
 compile.
 
 Before POSIX invented socklen_t, the type was almost universally int.
 The reason socklen_t appeared was that somebody started using size_t
 and this caused problems. I think it was DU on Alpha, because there
 size_t is not the same size as int so it mattered.
 
 As a result of this, though, everything since then defines socklen_t.
 So when it's really not defined, the proper type to insert is "int".
 
 (Meanwhile, whether it's signed or not is almost totally irrelevant as
 it's only used for interfacing.)
 
  >  However, actually this is a slight red herring as it is defined on my
  >  system, but the configure script is broken as it is including
  >  rpc/types.h which is not present, hence the use of the fallback which
  >  then fails as socklen_t is redefined.
 
 That would be a different bug. Let's fix that instead.
 
 Christos, please revert...
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost