http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/net...
> The <netinet/in.h> header shall define the sockaddr_in structure that includes at least the following members: [...]
The "at least" is the keyword. Additional members in the struct are allowed by POSIX. You have to expect and handle them according to the standard.
Is there a blanket requirement somewhere in POSIX which says that whenever a structure may have members in addition to the required ones, these members must be initialized (and specifically to zero) when the application creates such a structure and passes it to a library function?
(If so, why are they repeating that requirement for struct sockaddr_in6?)
In any case, does the issue reproduce on FreeBSD? If I google for this bind problem, it only appears to be reported against Mac OS X, and no other Unix, historic or current.
https://groups.google.com/forum/#!topic/comp.std.c/zl15FkixB...
If a standard structure may have additional members, those do not have to be initialized by the program, unless the requirement is explicit somewhere. For example, we do not have to initialize members of "struct tm" other than the standard ones when calling asctime; there is no wording which absolves asctime of behaving as required if those members are not initialized.
The same reasoning applies to the POSIX bind function and the members of struct sockaddr_in. (But not struct sockaddr_in6, for which initialization requirements are specified).
About sockaddr_in, POSIX-2001, 2004 edition[1] has to say:
10004 The <netinet/in.h> header shall define the sockaddr_in structure that includes at least the
10005 following members:
10006 sa_family_t sin_family AF_INET.
10007 in_port_t sin_port Port number.
10008 struct in_addr sin_addr IP address.
However, about IPv6 it says:
10016 The <netinet/in.h> header shall define the sockaddr_in6 structure that includes at least the
10017 following members:
10018 sa_family_t sin6_family AF_INET6.
10019 in_port_t sin6_port Port number.
10020 uint32_t sin6_flowinfo IPv6 traffic class and flow information.
10021 struct in6_addr sin6_addr IPv6 address.
10022 uint32_t sin6_scope_id Set of interfaces for a scope.
10023 The sin6_port and sin6_addr members shall be in network byte order.
10024 The sockaddr_in6 structure shall be set to zero by an application prior to using it, since
10025 implementations are free to have additional, implementation-defined fields in sockaddr_in6.
[1]: The current UNIX standard is UNIX V7, which corresponds to SUSv4, which corresponds to the POSIX-2008. However, macOS is certified UNIX under the previous version, UNIX 03, which corresponds to SUSv3, which corresponds to POSIX-2001.
The API is extensible in that we can introduce new address types, and overlay new structures. You can implement a new network "foo", then in the API add AF_FOO address family enumeration and a struct sockaddr_foo which exhibits whatever members you want (which are documented and must be initialized).
The AF_INET family has only sin_family, sin_addr and sin_port. If we init these, we are good to go.
If you want a struct similar to struct sin_addr, but with more fields that are user-visible and must be initialized, you must introduce a new derived type AF_INET_SPECIAL along with struct sockaddr_in_special.
> Enforcing this rule leads to more robust and portable code.
Enforcing this rule ensures that correct code that works everywhere breaks on (i.e. does not cleanly port to) Mac OS.