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

["jdthood at gmail dot com" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #9 from Thomas Hood <jdthood at gmail dot com> ---
(Drat — sorry for the duplicate comment #6. If someone has the rights, please
delete comment #6.)

In general I think we should try to follow the RFC — preferably, if reasonable,
as it has already been interpreted by other significant unixes.

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 omit ADDRFAMILY and NODATA which are not mentioned in RFC3493.

The question about NONAME is mainly the question which of these classes it
falls into. 

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

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

Agreed, although it is true in some sense that there is no such domain name in
DNS as the null name.

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

FAIL means that a remote fault occurred whereas SYSTEM means that a local fault
occurred? I can imagine that for many clients this won't make any difference.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-19121-listarch-glibc-bugs=sources.redhat.com@sourceware.org Fri Jul 12 10:25:20 2013
Return-Path: <glibc-bugs-return-19121-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 23430 invoked by alias); 12 Jul 2013 10:25:20 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 22701 invoked by uid 48); 12 Jul 2013 10:25:14 -0000
From: "mattyclarkson at gmail dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug dynamic-link/15733] New: elf/elf.h duplicate dynamic section tag
Date: Fri, 12 Jul 2013 10:25:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: dynamic-link
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mattyclarkson at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-15733-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-07/txt/msg00062.txt.bz2
Content-length: 866

http://sourceware.org/bugzilla/show_bug.cgi?id\x15733

            Bug ID: 15733
           Summary: elf/elf.h duplicate dynamic section tag
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: dynamic-link
          Assignee: unassigned at sourceware dot org
          Reporter: mattyclarkson at gmail dot com

704: #define DT_FLAGS    30        /* Flags for the object being loaded */
705: #define DT_ENCODING    32        /* Start of encoded range */
706: #define DT_PREINIT_ARRAY 32        /* Array with addresses of preinit
fct*/

These are "Legal values for d_tag (dynamic entry type)" but the DT_ENCODING and
DT_PREINIT_ARRAY are the same (32).  Is this a bug or is this by design?

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