What address families can getaddrinfo return?

There is no guarantee of any kind. When I have invented my own protocol and assigned a number (locally), and my protocol can resolve the name your program gave, it is permissible to return a sockaddr for my address family.

Basically, if you pass AF_UNSPEC, you can do either of two things:

1. live dangerously, assume that PF_* constants map to AF_* constants, create a socket of that type and connect it, giving you instant support for my homebrew protocol, or, better,

2. ignore any result that has an address family you do not understand and proceed to the next one.

You need to be aware that it is quite possible that a name can be looked up but has no addresses of the desired type. When doing a lookup with AF_UNSPEC, you will get a positive lookup result then and need to create the error condition yourself.

As the ideal behaviour for an app is to fall back on other results in case the first one is not working (think DNS round-robin with a failed server), this can be achieved by iterating over the results until one succeeds and adjusting the error cause (i.e. start with "no addresses of required type", and if you find one and connection fails, switch to "destination unreachable").

POSIX says "If the ai_family field to which hints points has the value AF_UNSPEC, addresses shall be returned for use with any address family that can be used with the specified nodename and/or servname." (POSIX getaddrinfo(3)) and "A value of AF_UNSPEC for ai_family means that the caller shall accept any address family."

In fact, even the linux manpage doesn't exactly match what you say: "either IPv4 or IPv6, for example"; OpenBSD says "When ai_family is set to PF_UNSPEC, it means the caller will accept any protocol family supported by the operating system.", so I'll take it that it just means "whatever" (compatible with the other parameters).

I really don't know what strings one should pass getaddrinfo, sorry.

The range of AF_* values that can be returned is limited only by the size of the struct's type. It is perfectly legitimate for a custom driver/network to return its own addresses. You, of course, are limited to those you have headers for to match the arbitrary values against so as to understand the semantics of using a particular endpoint.

While you could try to create a total enumeration of all possible AF_* symbols, without a header that defines its value to match what the OS drivers are using to designate that protocol, the names are meaningless. Here are just a few that I found:

AF_IPX, AF_APPLETALK, AF_NETROM, AF_BRIDGE, AF_AAL5, AF_X25, AF_BRIDGE, AF_BLUETOOTH, AF_DECnet, AF_ATMPVC, AF_ROSE, AF_NETBEUI, AF_NETLINK, AF_ASH, AF_ECONET, AF_ATM_SVC, AF_SNA, AF_IRDA, AF_PPPOX, AF_WANPIPE, AF_LLC, etc, etc, etc.

Linux, being linux, has most of those in socket.h, but those values aren't guaranteed to be valid outside of that kernel and those drivers.