mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: Remaining tasks on resolver overhaul
Date: Mon, 2 Jun 2014 14:54:48 -0400	[thread overview]
Message-ID: <20140602185448.GH507@brightrain.aerifal.cx> (raw)
In-Reply-To: <538C51B0.20308@skarnet.org>

On Mon, Jun 02, 2014 at 11:28:00AM +0100, Laurent Bercot wrote:
> >>- AI_ADDRCONFIG -- but maybe the current implementation of it as a nop
> >>   is actually best
> >
> >+1
> >(nop is best, guessworks are harmful, code simplification is useful)
> 
>  +1. AI_ADDRCONFIG has always been a logical aberration: the underlying
> DNS transport and capabilities of the machine have nothing to do with the
> data transmitted via DNS. If a domain has an AAAA record, I expect
> getaddrinfo() to return it, whether my machine is IPv6-capable or not.

So far all the comments I've heard on AI_ADDRCONFIG have been in favor
of leaving it a nop. IMO this is perfectly conforming as long as the
system has 127.0.0.1 and ::1 since "an IPv4 address is configured on
the local system" and "an IPv6 address is configured on the local
system".

Personally I'm not as strongly opposed to AI_ADDRCONFIG actually doing
something as some people are, since it's NOT the default; you have to
request it. Actually glibc sets it automatically when hints==NULL,
which is non-conforming (hints==NULL implies flags==0 per the
standard) so this may be why so many people hate it. If we added
support and followed the letter of the standard exactly (treating ::1
and 127.0.0.1 as configured addresses) it would behave as a nop on
basically all real-world systems except those where either IPv4 or IPv6
has been fully ripped out, where the admin/user actually may want to
be suppressing one or the other.

In any case I'm in no hurry to make changes on this item since there
seems to be no demand for such functionality.

Rich


      reply	other threads:[~2014-06-02 18:54 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-02  9:18 Rich Felker
2014-06-02  9:51 ` u-igbb
2014-06-02 10:28   ` Laurent Bercot
2014-06-02 18:54     ` Rich Felker [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140602185448.GH507@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).