Marek Habersack grendel@caudium.net writes:
What's more, some code might want to force a specific family for some reason - remember that AF_INET, AF_UNIX and AF_INET6 are not the only families available (STCP comes to mind, it has its own family, I think).
Does open_socket handle AF_UNIX? I didn't know that. As for STCP, I haven't read up on that, but I'd be surpriced if that's a new address family, rather than just new protocol (third argument to socket, with name-to-number mapping in /etc/protocols).
and have the code examine the address to figure out which address family it is. (For numerical addresses, that's trivial, for dns names
I thought about it, but I usually stick to the rule that too much automation is bad - in the case of fairly low-level code like the open call, I think this (optional) flexibility is quite justified.
What I didn't like about it, I think, was the default setting. I don't think there should be a configurable (global or per socket) default. Either the family argument should be mandatory, or there should be a well defined, constant, default behaviour. Getting the family from looking at the address string (or resolving it using DNS) seems like the most reasonable default behaviour to me.
Yep, that's another issue that would have to be dealt with. Actually, IPv6 is differentiated to IPv4 in DNS by using a different type of the address record - AAAA instead of A, respectively. But then, if a DNS resolver returns addresses from all families, you are unable to guess which one the caller really wants - specifying the family is very helpful here.
The resolver should return both ipv4 and ipv6 addresses. The user of a DNS name should not need to know in advance if that name refers to a machine with an IPv4 or IPv6 address. Actually, I think that a well-behaved pike program that uses DNS names to refer to hosts should not even need to know that IPv4 and IPv6 are different, network programming should be easier in Pike than in C.
/Niels