Date: Sun, 29 Oct 2000 09:55:30 -0600 From: "Jacques A. Vidrine" <n@nectar.com> To: itojun@iijlab.net Cc: freebsd-net@freebsd.org Subject: Re: getaddrinfo and the UNIX domain Message-ID: <20001029095530.A26020@spawn.nectar.com> In-Reply-To: <25904.972806047@coconut.itojun.org>; from itojun@iijlab.net on Sun, Oct 29, 2000 at 04:54:07PM %2B0900 References: <20001028163909.A77420@hamlet.nectar.com> <25904.972806047@coconut.itojun.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Oct 29, 2000 at 04:54:07PM +0900, itojun@iijlab.net wrote: > NRL getaddrinfo supports PF_UNIX (= PF_LOCAL) family. as NRL > getaddrinfo is in linux distributions, i belive openldap guys are > assuming that linux behavior is correct. > > from standardization standpoint, all documents are silent about which > address family are mandatory to be supported. as getaddrinfo is an > "address family independent service address/name lookup" function, one > can claim that everything has to be supported. however, we have some > limit in supports. for example, if we try to support PF_UNIX, it is > not very compatible with current definition of getaddrinfo flags (like > NI_NUMERICSERV). i don't think we can convert /tmp/some-socket into > some numeric. > > how critical is it for openldap? It is not critical -- it is easily worked around. I do have to admit, however, that having getaddrinfo handle PF_LOCAL sockets in some fashion does make the application code a bit cleaner, in that it eliminates a special case. I think that if getaddrinfo were to support PF_LOCAL, then it could just return errors for flags that make no sense, like NI_NUMERICSERV. Thanks, -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org 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?20001029095530.A26020>