Re: getaddrinfo() loses on RedHat 6.0

>>>>> "H" == Hideaki YOSHIFUJI <yoshfuji(a)v6.linux.or.jp&gt; writes: H> What do you mean by "which implementation"? H> (gethostbyname() vs getaddrinfo() ???) I mean, which implementation of getaddrinfo? Early implementations will be buggy. For example, the implementations of getaddrinfo() in AIX 4 and in Red Hat 6.0 are claimed to be buggy. So what is a free software project to do, when it is not primarily a networking application, but uses the network incidentally? Most users of XEmacs do not use the network functionality much. So how to get the most reliable XEmacs? We have an autoconf test for getaddrinfo(). Perhaps we: - Use the old interface gethostbyname by default, and provide a --with-getaddrinfo configure switch for the adventurous. We change to make --with-getaddrinfo the default some time in the future, when "most" users have a system that implements getaddrinfo() well.

- Use Hideaki YOSHIFUJI's suggestion below. H> One solution against the problem that it would take long time to H> resolve names is to define a new runtime-configuration variable H> which selects protocol family being given to getaddrinfo() H> through 'hints': H> : H> memset(&hints, 0, sizeof(hints)); H> hints.ai_familt = af; /* <= set this value by configuration variable: H> PF_UNSPEC: IPv6->IPv4 (default) H> PF_INET : IPv4 H> PF_INET6 : IPV6 H> xemacs' default should be PF_UNSPEC, but H> it may be configurable by autoconf. H> Even in this case, xemacs MUST allow H> users to set this value through H> runtime-variable by thamselves: H> Red Hat can set configuration variable H> PF_INET by default, but users MUST be H> able to change that to PF_UNSPEC. */ But this depends on our knowledge of what REAL WORLD implementation do today. Hideaki, are you saying that setting hints.ai_family to PF_INET will "work" for almost all implementations that actually have a getaddrinfo function. For example, is this likely to avoid problems on AIX 4? Martin