[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: bin/48063: incorrect definition of socklen_t
The following reply was made to PR bin/48063; it has been noted by GNATS.
From: David Holland <dholland-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:
> "<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
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
Main Index |
Thread Index |