On Fri, Feb 15, 2019 at 03:07:15PM +0100, Claudio Jeker wrote:
> Another diff to ease portability of bgpd. The sa_len field in struct
> sockaddr does not exist on Linux so instead of using it pass a length to
> the function (e.g. like bind(2) and connect(2) and do the same when
> passing around struct sockaddr_storage in the listener case.
> The remaining sa_len, sin_len, sin6_len and ss_len usages are in very
> OpenBSD specific files.
>
> --
> :wq Claudio
>
> Index: bgpd.h
> ===================================================================
> RCS file: /cvs/src/usr.sbin/bgpd/bgpd.h,v
> retrieving revision 1.369
> diff -u -p -r1.369 bgpd.h
> --- bgpd.h 15 Feb 2019 11:38:06 -0000 1.369
> +++ bgpd.h 15 Feb 2019 13:51:28 -0000
> @@ -220,11 +220,12 @@ struct bgpd_addr {
> #define LISTENER_LISTENING 0x02
>
> struct listen_addr {
> - TAILQ_ENTRY(listen_addr) entry;
> - struct sockaddr_storage sa;
> - int fd;
> - enum reconf_action reconf;
> - u_int8_t flags;
> + TAILQ_ENTRY(listen_addr) entry;
> + struct sockaddr_storage sa;
> + int fd;
> + enum reconf_action reconf;
> + socklen_t sa_len;
> + u_int8_t flags;
> };
What's the use of maintaining and passing around sa_len if the sa member is
a fixed size? (Well, other than being a more straightforward patch.)
AFAIK the only variably sized sockaddr structure is sockaddr_un. Domain
socket paths can be longer than what sockaddr_un (or sockaddr_storage) can
nominally fit, but if the sa member is a fixed size then it's irrelevant and
you can always derive the sa object size from .sa_family or .sun_family +
.sun_path.
