Kacheong Poon writes: > James Carlson wrote: > > > Using the same interface in many places means that code using this > > stuff becomes simpler and more uniform. I think that's generally a > > good thing. > > > In the particular case in this thread, does embedding > a sockaddr_storage (not a pointer to sockaddr_*) in the > vrrp_vr_t struct actually make the code handling simpler?
No. I was just addressing the issue of using sockaddr structures for addresses. > I guess we are not talking about innovation here. We are > talking about writing new code which wants to pass an IP > address around. The question is why it is preferred to > use sockaddr_storage. Why does it look like a "fracture" > in the code base here if sockaddr_storage is not used? I'm not against using something other than sockaddr_storage here. A union of sockaddr_in and sockaddr_in6 would be fine. I just find it hard to argue against sockaddr _in general_. > Anyway, I think forcing new code which needs to pass an IP > address around to use sockaddr_storage seems inappropriate > to me. I can go along with that. It's unclear to me, though, who or what should be using this interface at all, so I'm missing some context on how important the issue should be. Part of what's up in the air here is whether this library needs to be public at all. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
