tags 182186 fixed-upstream thanks Time to revisit another ancient bug report...
> On Sat, Aug 23, 2003 at 20:25:52 +0200, Martin Schulze wrote: > > J.H.M. Dassen (Ray) wrote: > > > Our getaddrinfo(3) does not document the consistency requirements (e.g. > > > the need to provide a ai_socktype hint in order to be able to resolve a > > > numeric port number), which limits its usefulness. > > > > > > The OpenBSD getaddrinfo(3) does document them (see e.g. > > > http://resin.csoft.net/cgi-bin/man.cgi?section=3&topic=getaddrinfo). > > > Perhaps that information can be merged? > > > > Could you propose a patch? > > Not at the moment - I barely have time to keep up with my own packages. > > > I'm unable to see what you believe is missing and needs to be merged > > The BSD manpages has this section which explains additional requirements > that need to be fulfilled for getaddrinfo() to work; there is no equivalent > information in the manpage we ship. > > :The arguments to getaddrinfo() must sufficiently be consistent and unam- > : biguous. Here are pitfall cases you may encounter: > : > : o getaddrinfo() will raise an error if members of the hints structure > : are not consistent. For example, for internet address families, > : getaddrinfo() will raise an error if you specify SOCK_STREAM to > : ai_socktype while you specify IPPROTO_UDP to ai_protocol. > : > : o If you specify a servname which is defined only for certain > : ai_socktype, getaddrinfo() will raise an error because the arguments > : are not consistent. For example, getaddrinfo() will raise an error > : if you ask for ``tftp'' service on SOCK_STREAM. > : > : o For internet address families, if you specify servname while you set > : ai_socktype to SOCK_RAW, getaddrinfo() will raise an error, because > : service names are not defined for the internet SOCK_RAW space. > : > : o If you specify a numeric servname, while leaving ai_socktype and > : ai_protocol unspecified, getaddrinfo() will raise an error. This is > : because the numeric servname does not identify any socket type, and > : getaddrinfo() is not allowed to glob the argument in such case. > > I reported this bug while I was trying to make an application IPv6-aware and > couldn't figure out (by our documentation) why getaddrinfo() wasn't doing > what I expected it to do. Googling brought me to the BSD manpage which did > clear things up for me. It would have helped a little if you could have identified which of the above four items apply on Linux/glibc. As far as I can tell, they don't all apply, though most of them do. (The last one does not seem to -- I'm not sure whether it "should" -- i.e., whether this is a bug against specified behavior.) > > -- and I don't want to rewrite the entire manpage since that won't be > > accepted upstream anyway: > > Doesn't it make sense then to just forward this bug report upstream and have > them amend the manpage in a way that is acceptible to them? Well, I'm the upstream, and I've done some testing of the four cases listed above. The first 3 seem to be relevant for Linux, but not the last one. I've made some corresponding updates to the man page (as well as a few other updates) -- see below. These changes will be in upstream 3.12. Let me know if you think anything else is required. Thanks, Michael --- a/man3/getaddrinfo.3 +++ b/man3/getaddrinfo.3 @@ -476,8 +476,14 @@ The name server returned a temporary failure indication. Try again later. .TP .B EAI_BADFLAGS -.I ai_flags -contains invalid flags. +.I hints.ai_flags +contains invalid flags; or, +.I hints.ai_flags +included +.B AI_CANONNAME +and +.I name +was NULL. .TP .B EAI_FAIL The name server returned a permanent failure indication. @@ -513,9 +519,35 @@ was not a numeric port-number string. .B EAI_SERVICE The requested service is not available for the requested socket type. It may be available through another socket type. +For example, this error could occur if +.I service +was "shell" (a service only available on stream sockets), and either +.I hints.ai_protocol +was +.BR IPPROTO_UDP , +or +.I hints.ai_socktype +was +.BR SOCK_DGRAM ; +or the error could occur if +.I service +was not NULL, and +.I hints.ai_socktype +was +.BR SOCK_RAW +(a socket type that does not support the concept of services). .TP .B EAI_SOCKTYPE The requested socket type is not supported. +This could occur, for example, if +.I hints.ai_socktype +and +.I hints.ai_protocol +are inconsistent (e.g., +.BR SOCK_DGRAM +and +.BR IPPROTO_TCP , +repectively). .TP .B EAI_SYSTEM Other system error, check -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
