This is for [glibc-2.3.3-200407231111],
This refers to IEEE 1003.1, 2004 Edition, "Information technology --
Portable Operating System Interface (POSIX) --
Part 2: System Interfaces", getaddrinfo().
] If the AI_NUMERICHOST flag is specified, then a non-null nodename
] string supplied shall be a numeric host address string. Otherwise,
] an [EAI_NONAME] error is returned. This flag shall prevent any
] type of name resolution service (for example, the DNS) from being
] If the specified address family is AF_INET or AF_UNSPEC, address
] strings using Internet standard dot notation as specified in
] inet_addr() are valid.
] If the specified address family is AF_INET6 or AF_UNSPEC,
] standard IPv6 text forms described in inet_ntop() are valid.
This means that both inet_addr() and inet_ntop() are valid if the
specified address family is AF_UNSPEC.
Not conforming to this can negatively impact backward
compatibility in applications that have been upgraded
from using inet_addr() to using getaddrinfo().
A proposed patch follows. I wrote it and I am putting it in the public
Created attachment 149 [details]
patch for POSIX AI_NUMERICHOST support and address notation validity in getaddrinfo()
The patch looks good to me (except formatting and missing ChangeLog entry).
2004-08-05 Ulrich Drepper <email@example.com>
* sysdeps/posix/getaddrinfo.c (gaih_inet): Recognize all the IPv4
numeric address formats inet_addr knows.
(getaddrinfo): Allow AI_NUMERICSERV flag.
If neither IPv4 nor IPv6 inerface is present we cannot make any
decision for AI_ADDRCONFIG. Fail if AI_NUMERICSERV is set and the
string is not just a number. Remove useless freeaddrinfo call.
* resolv/netdb.h (AI_NUMERICSERV): Define.
Based on a patch by firstname.lastname@example.org.
*** Bug 298 has been marked as a duplicate of this bug. ***
The new logic on line 578 of getaddrinfo.c
if (__inet_aton (name, (struct in_addr *) at->addr) != 0)
is incorrect. Only the form recognized by inet_pton() should be valid
when req->ai_family == AF_INET6 according to the standard. This is no
longer the case now. The logic in the patch I submitted is correct and
I believe it is not possible to reduce it to a liter form and still
No. The AF_INET6 case is only talking about the IPv6 addresses. Not the format
for addresses mapped from IPv4 to IPv6. The standard does not really describe
the format of IPv4 addresses if AF_INET6 with AI_V4MAPPED is used. To make it
consistent, the use of inet_aton is best.
I notice the new line 588 in getaddrinfo.c
at->family = AF_INET6;
This is right and I think a similar line should be added after line 608
*(uint32_t *) at->addr = ((uint32_t *) at->addr);
in the "opposite" case
at->family = AF_INET;
with new braces of course.
Correct. Although one more if condition is missing since we should not assume
there is no third or fourth protocol.