Make getnameinfo(3) salen requirement less strict

[hrs]

Summary

getnameinfo(3) currently returns EAI_FAIL when salen is not equal to
the length corresponding to the value specified by sa->sa_family.
However, POSIX does not require it and RFC 4038 Sec.6.2.3 shows
an example passing sizeof(struct sockaddr_storage) to salen.

This patch makes the requirement less strict by accepting
salen up to sizeof(struct sockaddr_storage). It also includes
two more changes: one is to fix return values because SUSv4 requires
EAI_FAMILY when the address length is invalid, another is to fix
sa_len dependency in PF_LOCAL.

[ae]

lib/libc/net/getnameinfo.c

131 ↗

(On Diff #39957)

I'm not sure that this check is useful. Why we need to restrict the size of this buffer if it is enough to keep needed structure?

[hrs]

lib/libc/net/getnameinfo.c

131 ↗

(On Diff #39957)

It is because salen argument must contain the length of the address pointed to by sa, not an arbitrarily long buffer (this is what SUSv4 specifies). In practice, it is harmless to have a longer salen as far as sa actually points the longer buffer, but such a longer salen is naturally not equal to the actual length of the address. I think the address-family-independent nature of this API implies that the length of the address is equal to or shorter than sizeof(struct sockaddr_storage) at least. This is the reason why I think it is still reasonable to loosen the restriction to the range of (afd->a_socklen <= salen < sizeof(struct sockaddr_storage)) while I still believe the programmer should set salen to the exact value depending on sa_family from the beginning.