Date: Mon, 16 Jul 2001 16:41:40 +0100 From: Ian Dowse <iedowse@maths.tcd.ie> To: itojun@iijlab.net Cc: freebsd-net@FreeBSD.ORG, Bernd Walter <ticso@mail.cicely.de>, Hajimu UMEMOTO <ume@mahoroba.org> Subject: Re: how to get AF_LOCAL from getaddrinfo() Message-ID: <200107161641.aa27724@salmon.maths.tcd.ie> In-Reply-To: Your message of "Tue, 17 Jul 2001 00:20:31 %2B0900." <14350.995296831@itojun.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <14350.995296831@itojun.org>, itojun@iijlab.net writes:
>
> the change will break a lot of applications. specifically:
Thanks for your comments. I may not have explained this very well;
the proposed change only takes effect when getaddrinfo() is given
a `hints' structure with hints->ai_family set to PF_LOCAL. No
existing applications have any reason to set hints->ai_family to
PF_LOCAL, so they should not see any change in behaviour.
I certainly do not intend to have any PF_LOCAL addresses returned
by a wildcard match, nor even by something like
getaddrinfo(NULL, "/tmp/sock", NULL, &ai)
which might be considered "unambiguous". The semantics of PF_LOCAL
addresses are just too different from INET/INET6, so I had purposefully
arranged that PF_LOCAL addresses would only be returned when
specifically asked for.
Does that restriction make the proposal more reasonable?
> also, with AF_UNIX, {NI,AI}_NUMERIC{HOST,SERV} does not have proper
> interpretation. you will need to pick some interpretation (maybe
> you may want to follow what NRL did for linux glibc/NRL IPv6 stack)
The approach I took was to ignore these flags. There is no concept
of numeric addresses for PF_LOCAL addresses, but applications
setting *_NUMERIC* just wishing to avoid a DNS lookup shouldn't
need to specifically avoid passing these flags in the PF_LOCAL case.
Ian
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200107161641.aa27724>
