Under NetBSD, the Unix.sockaddr function does not work correctly, since the sin_len/sin6_len fields are not set. The attached patch solves the problem for me, and should not hinder on other operating systems.

Unfortunately, the patch does hinder very much on other operating systems: for instance, Linux has neither sin_len nor sin6_len fields.

Concerning sin_len, Stevens says that it's not part of POSIX 1g and that it's for kernel internal use -- the kernel should *not* expect the user to set it. If NetBSD thinks otherwise, it's a NetBSD problem.

Concerning sin_len6, there's an #ifdef to be put around assignments to sin6_len.

always gives a Not_found exception, whereas with the patch, it correctly returns.

The NetBSD implementation of getnameinfo explicitly checks for sockaddr.sa_len not being 0, otherwise it fails. This seems to be a BSDism, though, as you say. Would it help if I put an #ifdef SYS_bsd around it and changed the assignments to sin_len/sin6_len to sa_len?

I agree with you that setting the sa_len field in get_sockaddr() should be enough.

A Web search for "getnameinfo sa_len" reveals the portability nightmare: some systems (BSD and perhaps others) have sa_len and check it in getnameinfo(), and other systems (Linux and perhaps others) do not have sa_len at all. So it's #ifdef time...

I don't think #ifdef SYS_bsd is appropriate: the SYS_xxx Caml macros are not defined when compiling otherlibs/, and other systems beyond BSD may need sa_len to be set. A special "configure" test is probably needed.

Looking at the issue, it appears that a correct fix is to use #ifdef SIN6_LEN to know whether the OS does use BSD 4.3 sockets, or BSD 4.4 sockets.
See RFC 2553, at the top of page 8:
" The only differences between this data structure and the 4.3BSD
variant are the inclusion of the length field, and the change of the
family field to a 8-bit data type. The definitions of all the other
fields are identical to the structure defined in the previous
section.

Systems that provide this version of the sockaddr_in6 data structure
must also declare SIN6_LEN as a result of including the
<netinet/in.h> header. This macro allows applications to determine
whether they are being built on a system that supports the 4.3BSD or
4.4BSD variants of the data structure.
"http://www.ietf.org/rfc/rfc2553.txt [^]

The patch-ba file seems to fix the issue both for netbsd and solaris (which does not have sa_len)