< said:
> to compare 0 bytes worth of data and returns success). In my opinion,
> this is a bug: either the equal() macro should return false, or the
> zero length field should be detected by a sanity check and the function
> should return EINVAL.
OK, I'll agree that this is a bug.
-GAWollman
-
Of all the gin joints in all the towns in all the world, Garrett Wollman
had to walk into mine and say:
> < said:
>
> > a struct sockaddr_dl will be used. However, the user is supposed to
> > pass the address using a struct ifreq, and struct ifreq uses struct
> > sockaddr, not struct sockaddr_d
< said:
> a struct sockaddr_dl will be used. However, the user is supposed to
> pass the address using a struct ifreq, and struct ifreq uses struct
> sockaddr, not struct sockaddr_dl.
This is called ``poor man's inheritance''.
I believe it is an error for any code to use AF_UNSPEC for any purpos
After experimenting some more, I've come to the conclusion that trying to
manually add a non-IP ethernet multicast address doesn't work properly.
The ether_resolvemulti() assumes that addresses will be specified as
either AF_LINK or AF_INET; if the family is AF_LINK, it assumes that
a struct sockad
