Date: Fri, 2 Mar 2018 12:32:40 +0000 From: Christophe Beauval <christophebeauval@hotmail.com> To: Hiroki Sato <hrs@FreeBSD.org> Cc: "freebsd-standards@freebsd.org" <freebsd-standards@freebsd.org> Subject: Re: Libc getnameinfo length requirement Message-ID: <VI1PR0402MB3711C2331551B00ABF42B674A2C50@VI1PR0402MB3711.eurprd04.prod.outlook.com> In-Reply-To: <20180302.111804.1733124916347516747.hrs@allbsd.org> References: <VI1PR0402MB371177DFA52E8CC936FCDD00A2C60@VI1PR0402MB3711.eurprd04.prod.outlook.com> <20180302.111804.1733124916347516747.hrs@allbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello There is a typo in the comment: RFC 4018 is mentioned, this should be 4038. There is also a problem with relying on the sa->sa_len presence and sort=20 of undoing two earlier patches from 17th April 2005, where according to=20 the commit comment, sa->sa_len is not required by POSIX:=20 https://github.com/freebsd/freebsd/commit/90a7ec34ec2cf5e36aeb76ff35c656f88= 0659274#diff-25ee506a989a23ae5d8904e113aa66d7=20 and=20 https://github.com/freebsd/freebsd/commit/ba35b6aa7602967dbfeb53dc1e32ba186= 8bd3e98#diff-25ee506a989a23ae5d8904e113aa66d7=20 . Kind regards Christophe Beauval Op 2/03/2018 om 3:18 schreef Hiroki Sato: > Hi, > > Christophe Beauval <christophebeauval@hotmail.com> wrote > in <VI1PR0402MB371177DFA52E8CC936FCDD00A2C60@VI1PR0402MB3711.eurprd04.= prod.outlook.com>: > > ch> Hello all > ch> > ch> This message after having presented the problem below in the freenode > ch> #freebsd and EFNet #bsdcode channels and being advised (amongst other= s) > ch> to use this mailing list. > ch> > ch> When I got strange errors (EAI_FAIL) from getnameinfo-calls in a priv= ate > ch> project, I investigated the freebsd/libc/net/getnameinfo.c source cod= e > ch> and stumbled upon the requirement (in the switch-statement at line 12= 7) > ch> that the "socklen_t salen" argument needs to be the exact same number= as > ch> "sizeof(struct sockaddr_in)" for the PF_INET protocol family and > ch> "sizeof(struct sockaddr_in6)" for the PF_INET6 protocol family. This > ch> fails when using a "sockaddr_storage" struct as first argument and ti= ed > ch> to this a "sizeof(struct sockaddr_storage)" as second argument, as ca= n > ch> be found as example in RFC 4038 on page 21 paragraph 6.2.3. For the > ch> PF_LOCAL protocol family a larger "salen" than it's used struct is al= so > ch> not allowed in that switch. > ch> > ch> A less strict requirement either allowing any larger size (like in > ch> glibc's implementation) or at least the size of "struct > ch> sockaddr_storage" (as suggested by hrs) would solve this problem. > > I have a patch to change getnameinfo() to accept a longer salen > (attached). I do not think there is a bad side-effect or impact for > backward compatibility. You can try test_getnameinfo.c to test the > difference. > > While I'm here, I changed the return value on error because SUSv4 > says EAI_FAMILY should be returned when the address length was > invalid. > > -- Hiroki
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?VI1PR0402MB3711C2331551B00ABF42B674A2C50>