Bug 296 - POSIX => AI_NUMERICHOST and address notation validity in getaddrinfo()
Summary: POSIX => AI_NUMERICHOST and address notation validity in getaddrinfo()
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: 2.3.3
: P2 enhancement
Target Milestone: ---
Assignee: GOTO Masanori
: 298 (view as bug list)
Depends on:
Reported: 2004-08-01 22:20 UTC by A. Guru
Modified: 2004-08-05 21:50 UTC (History)
3 users (show)

See Also:
Host: n/a
Target: n/a
Build: n/a
Last reconfirmed:

patch for POSIX AI_NUMERICHOST support and address notation validity in getaddrinfo() (1.40 KB, patch)
2004-08-01 22:23 UTC, A. Guru
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description A. Guru 2004-08-01 22:20:35 UTC
This is for [glibc-2.3.3-200407231111],
files sysdeps/posix/getaddrinfo.c
  and resolv/netdb.h.

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
] invoked.


] 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().

See <http://www.opengroup.org/onlinepubs/009695399/functions/getaddrinfo.html>
and <http://www.opengroup.org/onlinepubs/009695399/basedefs/netdb.h.html>.

A proposed patch follows.  I wrote it and I am putting it in the public
Comment 1 A. Guru 2004-08-01 22:23:36 UTC
Created attachment 149 [details]
patch for POSIX AI_NUMERICHOST support and address notation validity in getaddrinfo()
Comment 2 Jakub Jelinek 2004-08-05 00:01:07 UTC
The patch looks good to me (except formatting and missing ChangeLog entry).
Comment 3 Jakub Jelinek 2004-08-05 16:10:17 UTC
2004-08-05  Ulrich Drepper  <drepper@redhat.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 a.guru@sympatico.ca.
Comment 4 Jakub Jelinek 2004-08-05 16:11:43 UTC
*** Bug 298 has been marked as a duplicate of this bug. ***
Comment 5 A. Guru 2004-08-05 20:10:34 UTC
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
remain correct.
Comment 6 Ulrich Drepper 2004-08-05 20:19:20 UTC
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.
Comment 7 A. Guru 2004-08-05 20:24:46 UTC
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)[3];

in the "opposite" case

                 at->family = AF_INET;

with new braces of course.
Comment 8 Ulrich Drepper 2004-08-05 21:50:24 UTC
Correct.  Although one more if condition is missing since we should not assume
there is no third or fourth protocol.