bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: getaddrinfo test: ignore failure on AIX


From: Bruno Haible
Subject: Re: getaddrinfo test: ignore failure on AIX
Date: Tue, 15 Apr 2008 13:01:01 +0200
User-agent: KMail/1.5.4

Simon Josefsson wrote:
> 1) Supporting a complete list takes up a lot of size.  Not all projects
> use non-numeric service fields in getaddrinfo, so it can be wasteful.

Then what about a shorter list? Let's say, only the 20 to 100 protocols
defined by RFCs (because only they are likely to be relevant for free
software), not the thousands of proprietary protocols?

> 2) Hard coding the service <-> port mappings breaks the ability to
> modify port numbers by editing /etc/services or using NIS or whatever.

The getaddrinfo replacement would, of course, first try the system's
getaddrinfo, and only upon failure, look in its own table.

> 3) Detecting whether the system's internal getaddrinfo has failed only
> because of an unsupported service may be trickier.

Is it so tricky? When getaddrinfo("somehost", "foo", ...) fails:
  - If the errno code is one of the three we know about:
    - If "foo" is in our own table:
      Retry getaddrinfo("somehost", numeric-foo, ...).
    - Otherwise, if errno is EAI_NONAME or EAI_NODATA, try
      getaddrinfo("somehost", "80", ...). If that succeeds, return EAI_SERVICE,
      otherwise return EAI_NODATA (or should it be EAI_NONAME??).
  - Otherwise simply forward the system's getaddrinfo return code.

> We could add a wrapper
> to, on these error codes and for these systems, re-try any failed call
> for "https" with a call for "443", to see if that succeeds.

Yes.

> If we re-try (failed) queries for, say 'http', too, we may introduce
> surprising behavior: consider if the system maps 'http' to port 8080,
> and that lookup fails because no such service is registered [1], and we
> re-try it using port 80 instead, which could succeed.

I think users would consider it a feature, not a bug, if the replacement
function hides a bug in /etc/services. Service names are meant to be system
independent, after all.

Bruno





reply via email to

[Prev in Thread] Current Thread [Next in Thread]