>It looks like getaddrinfo() doesn't support PF_LOCAL, are there any plans
>to implement it, or would you welcome a patch? As I understand the
>OpenGroup's latest Base Spec draft, getaddrinfo() should support all
>supported families. Currently though the only implementations I've seen
>are by Craig Metz and Richard Stevens. The former is currently used in
>glibc. Adding PF_LOCAL support is pretty straightforward.

	I guess I have responded to almost exactly the same message a month
	ago somewhere... anyway...

	don't add it, at least right now.  before adding it, we need to
	implement checks likebelow, for all callers that are not compatible
	with PF_LOCAL.  it should be added only when we have done this for
	all callers (don't know when).
		for (res = res0; res; res = res->ai_next) {
			/* THE CHECK NEEDS TO BE ADDED */
			if (res->ai_family != AF_INET &&
			    res->ai_family != AF_INET6)
				continue;
		}

	IMHO, AF_LOCAL support is pretty good for experiments, but not really
	for practical uses.  it also does not have a good interpretation for
	NI_NUMERICxx.  KAME code have been having #if 0'ed fragment for
	PF_LOCAL, but it never got enabled as we experienced troubles with
	random third party applications when we enabled it.

	any idea what happens when we put AF_APPLETALK and other supports?
	what is the effect of additional delays in:
	- name resolution
	- socket-connect loop (and failure recoveries)
	what is the right ordering between AFs?
	i'm not really objecting about it, but i'm really curious about what
	should happen.

itojun