Re: bin/48063: incorrect definition of socklen_t

[christos%zoulas.com@localhost (Christos Zoulas)]

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

From: christos%zoulas.com@localhost (Christos Zoulas)
To: David Holland <dholland-bugs%netbsd.org@localhost>, 
gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: bin/48063: incorrect definition of socklen_t
Date: Sat, 20 Jul 2013 06:28:15 -0400

 On Jul 20,  6:12am, dholland-bugs%netbsd.org@localhost (David Holland) wrote:
 -- Subject: Re: bin/48063: incorrect definition of socklen_t
 
 | 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...
 
 Ok, I've ran into the rpc/types.h lossage before too (with amd). I agree,
 let's fix that instead.
 
 christos