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.

Reply via email to