I disagree with the sockaddr_storage removal part of this diff.
struct sockaddr_storage was added to Unix _precisely_ because the type
of code you have written was often found to be error prone.
It is longer. There aren't fewer casts after your change, there are
more. Since there are casts, it is possible for future changes to the
code to point at the wrong sockaddr and incorrectly initialize part of
it. If a 3rd protocol is ever added, it will become even more of a
mess, and 3 structs might exceed the size of sockaddr_storage.
We spent more than a decade putting sockaddr_storage into the tree,
and now you want to start going the other way?
Klemens Nanni <k...@cvs.openbsd.org> wrote:
> CVSROOT: /cvs
> Module name: src
> Changes by: k...@cvs.openbsd.org 2021/11/15 10:33:51
>
> Modified files:
> sbin/resolvd : resolvd.c
>
> Log message:
> Avoid huge sockaddr_storage
>
> sockaddr_{in,in6} are enough and a simple sockaddr pointer is enough to
> abstract them (sockaddr_storage is what worked for me, there is no other
> reason to use it).
>
> While here, be portable and pass a non-zero length to getnameinfo(3);
> while OpenBSD's implementation ignores it in the NI_NUMERICHOST case,
> at least the old KAME stack didn't.
>
> No functional change.
>
> Prodded by florian
> OK florian
>
