Bruno Haible <[EMAIL PROTECTED]> 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
