Description
The length of AF_UNIX addresses is not always the same as sizeof (struct sockaddr_un). The differences relate to how systems treat unnamed sockets obtained via socketpair(2), whether socketpair(2) descriptors manifest an accepting/connecting dichotomy, and whether systems make available the path name of named sockets to the connecting side. The following sizes have been documented (see PORTING.md for full table of results).
- 0 bytes (no address data, not even family) (AIX, Solaris) (yes, system call returned success)
offsetof(struct sockaddr_un, sun_family) + sizeof (sa_family_t)(path not set) (Linux)offsetof(struct sockaddr_un, sun_path) + 1(path with single NUL byte) (AIX, Solaris, *BSD, OS X)sizeof (struct sockaddr_un)(full path) (all) (Minix is only OS that always returns this size, regardless)
Furthermore, path lengths greater than sizeof ((struct sockaddr_un *)0)->sun_path may be possible on some systems. Finally, these same issues may apply to other address families which we might wish to support in the future.
Basically, we should consistently preserve, communicate, and make use of the struct sockaddr, socklen_t tuple instead of relying on our built-in sa_len() convenience function. It's verbose but unavoidable. (Too bad the 4.4BSD .sa_len member extension never caught on.) This will necessitate changing the signature of sa_ntop() and several other routines in our low-level C socket library. We should put calls to getsockname(2) and getpeername(2) inside a loop which can dynamically grow the address buffer, either changing the signature of existing functions which return address objects or adding new functions which return dynamically allocated address objects.