arguments to sockaddr_equal (sockaddr vs sockaddr_storage)?

[Jeremy Allison]

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 :-).

Jeremy.