On May 17, 2010, at 11:46, Mats Erik Andersson wrote: >> This isn't an ordering issue; standard gethostbyname() simply doesn't return >> IPv6 addresses. > > If the gethostbyname() present in libc6-2.7 (Lenny) and > libc6-2.10.2 (testing/Squeeze) are considered non-standard, > I could possibly agree.
I meant POSIX. But, I believe POSIX might allow for non-POSIX interfaces to alter the behavior; using them merely means you've got a non-conforming application. (I'm less familiar with the POSIX compliance specs than with, say, the ISO C ones.) > Using "options inet6", either implementation __does__ indeed > return IPv6 addresses. The manual page clearly state that > the call is allowed to do so! And yes, resolv.conf(5) warns > about using this optional setting. Yes, this would be a non-POSIX extension mechanism, and a dumb one since it causes the system to break reasonable POSIX applications (even if they're using deprecated IPv4-only interfaces). > This is close to my point, software should be written to use getaddrinfo(), > since 'hints.af_family = AF_INET' is the proper way of restricting to a > single family. The issue at hand must be to locate software which presupposes > that gethostbyname() returns addresses of true IPv4 size. My point was that a global "options inet6" flag was a dumb idea, and turning it on even dumber. (For that matter, I think the process-wide _res.options flag is also a bad idea, because your application may use library code that calls gethostbyname and expects IPv4 addresses.) I can't see that it *helps* anything. Except maybe the conversion to getaddrinfo, and it only "helps" that by encouraging developers to change their applications in the same way that you could "encourage" them by making gethostbyname() always call abort(). > Are you suggesting to remove gethostbyname() from glibc/eglibc entirely? > The manual page already states that gethostbyname() and gethostbyaddr() > are to be considered obsolete, and to be replaced by getaddrinfo() and > getnameinfo(). Only suggesting that it would've been a cleaner way to uncover all the gethostbyname uses than making them link properly but fail at run time. If you're going to break gethostbyname, better to catch remaining uses at compile time than (maybe) at run time. > >> And, if it's intentional, where was it discussed before the decision was >> made? Is there a more appropriate list for that discussion than this one?? >> > > We have to start somewhere, if nobody else does. Right? Start with discussion on the debian-ipv6 development list, not with code changes that break everything and catch people by surprise. > > I admit that the word "order" is not entirely to the point for > gethostbyname(), > but it is for getaddrinfo(). In a discussion earlier this year with Aurelien > Jarno, > I got confirmed that the default setting in Glibc changed between 2.7 and > 2.10.2, > in the sense that getaddrinfo() now orders IPv6 before IPv4 in the answer > list. > I did complain on this new behaviour, but had to do with the fact that any > software that does not loop through the output list from getaddrinfo() is > misconceived from the start. Sure, that sounds fine. Inconvenient for some who enable IPv6 but don't have good IPv6 connectivity, but still correct behavior. > In my view, the addressed problem with gethostbyname() is an offspring of > this deeper fact. If gethostbyname isn't selecting by address family, but instead is sensitive to the order in which getaddrinfo returns addresses of different families, then gethostbyname is broken. If getaddrinfo's behavior change causes this to result in gethostbyname malfunctioning, it's still a bug in gethostbyname. > > >> That makes me wonder if it's just a mistake, that should be corrected >> soon.... >> > > Doubtful. Said behaviour is now claimed to be standard in Ubuntu, Fedora, > SuSe; > you name them all. I assume maybe you mean development versions? I just updated an Ubuntu box to lucid (10.04) and threw together a test program. The host and the name being looked up both have IPv4 and IPv6 addresses, and the h_length field returned was 4; if I look up a name with IPv6 addresses only, gethostbyname returns a null pointer. This seems correct to me. > And as Aurelien Jarno pointed out, the order has never been > specified in any standard, every output strategy is equally valid. It is the > responsibility of the developer to identify the week assumptions. The ordering by getaddrinfo isn't an issue. The address-family handling by gethostbyname, as you describe it, is. IMO it *is* reasonable to assume that, if you write a POSIX-conforming program, gethostbyname will return IPv4 addresses. (Yes, the resolv code has an option to change that globally. Unless you rewrite *all* your network apps to anticipate non-POSIX behavior, it just breaks things. So, I argue that it's reasonable to assume that that option *won't* be used. I have no idea why it hasn't simply been deleted.) Ken -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
