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
