Skip site navigation (1)Skip section navigation (2)
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>