> Space may not be an issue here. But if you are talking about > using it generally, I guess it can be an issue in other cases. > What convenience routines are you referring to? For example, > do you mean a routine to compare two socket addresses? Then > I guess that the routine will need to be do comparison on all > the necessary fields.
Not necessarily. For instance, we could have different functions that compare different parts, or we could have the caller indicate what they want to compare. > But if a caller just uses sockaddr_storage to store an IP address and > wants to use the aforementioned compare routine, then I guess it will > need to do some unnecessary initialization to make it work. Or is > there a special family type to indicate IP address only in a > sockaddr_storage? See above. > > FWIW, this issue came up during the networking API talks a few of us were > > involved in several weeks back, and I took an AI to document a best > > practice here, so I'm interested in perspectives on this. > > To me, those sockaddr_* structs are used to store socket > address. Generalizing them to be used to store things like > single IP address seems not to be appropriate. If we want > to have common routines for IP address manipulation, we can > create a struct for storing all types (for now v4 and v6) IP > address, instead of using sockaddr_storage. Just an idea. I'm fine with that approach too. What I dislike is having every part of the code invent its own solution. I recall the ILB project wanted something to make it easy to represent IP address ranges as well (where the ranges may not fall on mask boundaries). Seems like a good thing to consider. -- meem _______________________________________________ networking-discuss mailing list [email protected]
