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: Simon Josefsson
Subject: Re: getaddrinfo test: ignore failure on AIX
Date: Tue, 15 Apr 2008 13:16:03 +0200
User-agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)

Bruno Haible <address@hidden> writes:

> 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?

Sure.  Hm.  I'd still prefer it to be optional though.

>> 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.

And on failure, getaddrinfo uses getservbyname, so what we are talking
about is a new gnulib module for getservbyname, isn't it?  That would
make it possible for me to avoid it, through a --avoid getservbyname.
So this approach would be fine.

>> 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.

The tricky part was how to deal with administrator's modifying
/etc/services.  I'm not sure it is reasonable to bother with such
systems though.

/Simon




reply via email to

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