arguments to sockaddr_equal (sockaddr vs sockaddr_storage)?

[Jelmer Vernooij]

Jeremy Allison wrote:
> On Sun, Apr 05, 2009 at 02:53:35PM +0200, Jelmer Vernooij wrote:
>   
>> Hi Volker,
>>
>> Volker Lendecke wrote:
>>     
>>> In master right now the function sockaddr_equal takes to
>>> const struct sockaddr *. In 3.3, it takes const struct
>>> sockaddr_storage.
>>>
>>> Didn't Jeremy go through big pain introducing
>>> sockaddr_storage when putting in IPv6 support? Why did we go
>>> to struct sockaddr again?
>>>
>>> I must have understood something wrong, can someone help me?
>>>   
>>>       
>> We used to use "struct sockaddr_in", not "struct sockaddr". The first is
>> specific to IPv4, "struct sockaddr" is a generic pointer for socket
>> addresses.
>>
>> "struct sockaddr" is only has a sa_family member that can be used to see
>> what it actually contains, so it can be casted (as is done in the socket
>> code) to (struct sockaddr_in, sockaddr_in6, sockaddr_un, etc). It is the
>> argument received e.g. by connect().
>>
>> The main difference between "struct sockaddr" and "struct
>> sockaddr_storage" is that the latter is guaranteed to be big enough to
>> hold a ipv6 or a ipv4 address. Since not all of these functions rely on
>> the argument being passed being at least the size of "struct
>> sockaddr_storage", this distinction is useful since Samba 4 can use the
>> functions that take a "struct sockaddr" with "struct sockaddr_in"
>> structures but can't use the functions that take a "sockaddr_storage"
>> argument.
>>     
>
> Then can you add a sockaddr_equal_samba4() function and
> revert the sockaddr_equal please ?
>
> I really don't want to have to go through this migration
> in our code again. The real fix is to change S4 to use
> sockaddr_storage, that is what needs to be done in the
> long run anyway. And no, I'm not doing it again :-).
sockaddr_equal() will still happily compare IPv6 and IPv4 addresses;
nothing has changed in terms of its functionality. It will just not
compare beyond the boundaries of "struct sockaddr_in" if the pointer
passed in has sa_family AF_INET. 

For other functions the size of the argument that's passed in *does*
matter independent of its family, e.g. for functions that set it such as
zero_sockaddr() or interpret_string_addr(). In case of those functions
the target pointer really has to be big enough to fit *any* socket address.

Cheers,

Jelmer