This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug network/15726] getaddrinfo() returns incorrect status


http://sourceware.org/bugzilla/show_bug.cgi?id=15726

--- Comment #10 from Kurt Roeckx <kurt at roeckx dot be> ---
(In reply to Thomas Hood from comment #9)
> In general I think we should try to follow the RFC â preferably, if
> reasonable, as it has already been interpreted by other significant unixes.

If the rfc is open for interpretation, I think we should try and get it (or
posix) fixed.

> The most important distinction is that between (1) not receiving an answer
> (whether this be because the function is not called properly, the network is
> down, there are no more file descriptors, whatever); and (2) receiving an
> answer (whether it be an answer containing the requested information or an
> answer containing the information that the name in question does not exist
> in the available sources).
> 
> 1. No answer received: AGAIN, BADFLAGS, FAIL, FAMILY, MEMORY, SERVICE,
> SOCKTYPE, SYSTEM
> 2. Answer was received: 0

I'm not sure I understand what you're trying to say here.  do both 1's and 2's
match?  Note that if it returns 0 it should have at least 1 address as result.

I also think the return value can be AGAIN in case the server does reply, but
for instance returns a temporary failure.  Or we only had the A reply and not
the AAAA reply.

> RFC3493 says very clearly that it must be returned at least in the case when
> neither nodename nor servname were supplied.

For some cases it's very explicit when which error code should be returned. 
For the the rest it just lists possible error code, not saying when which
should be returned.

> Zack Weinberg wrote:
> > I read that as specifying that EAI_NONAME is the appropriate error
> > return *both* when the name does not resolve (== NXDOMAIN at the
> > DNS level), *and* when "neither nodename nor servname were supplied".
> >
> > I think it's kind of unfortunate that EAI_NONAME is overloaded this way

I first thought it wasn't overloaded this way and was only for cases where you
supplied bad parameters.  Now I'm not sure anymore.


Kurt

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]