Fair enough, sorry for the noise. kn, could you please revert this?
On 2021-11-15 10:41 -07, "Theo de Raadt" <dera...@openbsd.org> wrote: > 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 >> -- I'm not entirely sure you are real.