Re: struct sockaddr_storage issues

[Ken Hornstein <kenh%cmf.nrl.navy.mil@localhost>]

>I agree, it's a good advice. I was looking at supporting IPv6 scope
>IDs some time ago, but at least for now, decided not to bother. I
>found the article which referred to getaddrinfo() issues. 
>
>https://blog.powerdns.com/2014/05/21/a-surprising-discovery-on-converting-ipv6-addresses-we-no-longer-prefer-getaddrinfo/

I feel compelled to point out that this article was written 8 years ago,
and the comments refers to some bugs in FreeBSD ... from 2006 (one
of the musl libc developers mentions they don't support AI_ADDRCONFIG,
but again, 8 years ago and I don't think that's relevant in any case).

The issues surrounding AI_ADDRCONFIG are well taken, but it seems
reasonable for getaddrinfo() to NOT convert a IPv6 numeric address when
you set AI_ADDRCONFIG since, as far as I can tell, that means "only
return a particular address family if it is configured on the box).  I
wrote a small test program and determined that if you ask getaddrinfo
to convert "::1" and you do NOT set AI_ADDRCONFIG, there are no extra
kernel calls to enumerate the available interfaces and seems to just
call inet_pton() or the equivalent.

Technically AI_ADDRCONFIG is NOT the default, but here's where
portability rears it's ugly head.  I see on at least some Linux systems
if you pass in a NULL pointer for the hints structure, AI_ADDRCONFIG
defaults to on.  You need to pass in a hints structure with ai_flags set
to 0.  On MacOS X things are slightly worse; if ai_flags is zero then
AI_ADDRCONFIG and AI_V4MAPPED_CFG are turned on.  You have to have a
non-zero ai_flags value to turn off the defauult AI_ADDRCONFIG (MacOS X
provides a special flag, AI_UNUSABLE, you can store in ai_flags if
if you really want ai_flags to be zero and not have AI_ADDRCONFIG
enabled).

--Ken