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

["zackw at panix dot com" <sourceware-bugzilla at sourceware dot org>]

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

Zack Weinberg <zackw at panix dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://pubs.opengroup.org/o
                   |                            |nlinepubs/9699919799/
                 CC|                            |zackw at panix dot com

--- Comment #5 from Zack Weinberg <zackw at panix dot com> ---
http://pubs.opengroup.org/onlinepubs/9699919799/ is the X/Open Issue 7 spec for
getaddrinfo, which is a little clearer about EAI_NONAME.  It's the exact same
text but with a paragraph break inserted at a key point:


    [EAI_AGAIN]
        The name could not be resolved at this time. Future attempts may
succeed.
    [EAI_FAIL]
        A non-recoverable error occurred when attempting to resolve the name.
    [EAI_NONAME]
        The name does not resolve for the supplied parameters.

        Neither nodename nor servname were supplied. At least one of these
        shall be supplied.
    [EAI_SYSTEM]
        A system error occurred; the error code can be found in errno.

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; it
would have been better to have a code specifically for a bad argument
combination (like the existing EAI_BADFLAGS).  Also, as an application
programmer I have no idea how I'm supposed to interpret EAI_FAIL.  At least
with EAI_SYSTEM there is an errno code to give additional guidance.

For context, as I understand it this grew out of a conversation about what
happens when you try to resolve a name during boot, and the network isn't yet
configured enough to provide name service.  On the operational level it seems
desirable for that always to produce EAI_AGAIN.

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