johansen at sun.com wrote: > On Fri, Aug 21, 2009 at 02:00:04PM -0700, johansen at sun.com wrote: >> This isn't actually what I was trying to convey. Above, I gave one >> example of how you could make the structure extensible, if you ever >> decide to add more error types. The sockaddr stucture is another >> similar approach, except that the information to determine what sockaddr >> is being used is kept with the socket state. In networking code, you >> supply a sockaddr_in for AF_INET sockets and a sockaddr_un for AF_UNIX >> sockets. The structures are variable length and have different members, >> but the interfaces the sockets code uses is flexible enough to cope with >> different sockaddr structures depending upon the protocol. > > To be entirely presice, the sockaddr structures have a member that > defines the family of the address. > > The generic sockaddr looks like this: > > sa_family_t sa_family /* address family */ > char sa_data[] /* socket address (variable-length > data) */ > > Whereas sockaddr_in and sockaddr_un look like the following, respectively: > > (in) > sa_family_t sin_family > in_port_t sin_port > struct in_addr sin_addr > unsigned char sin_zero[8] > > (un) > sa_family_t sun_family /* address family */ > char sun_path[] /* socket pathname */ > > Anyway, this is similar to what I described before, I believe. > > -j >
Yes, it is similar, I understood what you were getting at and had already been looking at this. -evan
