[Top][All Lists]

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

Re: Bogus getaddrinfo(3) on Darwin 9.2.2

From: Simon Josefsson
Subject: Re: Bogus getaddrinfo(3) on Darwin 9.2.2
Date: Wed, 17 Feb 2010 08:56:55 +0100
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux)

address@hidden (Ludovic Courtès) writes:

> Simon Josefsson <address@hidden> writes:
>> address@hidden (Ludovic Courtès) writes:
>>> What I meant to say is that it should return an error because resolving
>>> the ‘does-not-exist’ service fails.
>> Does it only fail (well, falsely succeed) for unknown services?
> When asked for a host name that does not resolve, it returns an error,
> as expected.

For unknown services?  Interesting.  What about known services, does it
resolve them correctly?

If the problem is that unknown services (for existing names) results in
port 0, we could work around that by wrapping the system getaddrinfo in
a check whether port is 0 and then return EAI_SERVICE.

>>> The key piece of info here is port = 0, which makes no sense.
>> Right, although I don't see a requirement in the getaddrinfo
>> documentation to fail if the service is not known, nor what it actually
>> means for a service to be "known" at all.
> Well, yeah, it doesn’t seem to be a requirement.
> Then again, what would be the point of ‘EAI_NONAME’ and ‘EAI_SERVICE’ if
> it weren’t used in such cases?
> And what’s the point of returning port = 0 for an unknown service?  It
> can only make programs fail gracelessly (e.g., connect() eventually
> fails) instead of providing a useful error message.

Right.  So we should consider "fixing" this in gnulib, but what exactly
to do is still a bit unclear.

>>>>> If it is indeed a bug, should we try to work around it in Gnulib?
>>>>> Any idea how this could be done?
>>>> Given that this is a bug (which isn't clear to me yet), we could work
>>>> around it.
>>> I agree in principle, of course, but I can’t think of a way to work
>>> around that since we’ll always have to rely on libc at one point or
>>> another.
>> It should be possible to look up services in other ways (getservbyname),
>> right?
> Yes, but what if getservbyname is similarly broken?  That wouldn’t be
> surprising if these functions are factorized.

We can replace broken getservbyname too.

>> If you use the getaddrinfo replacement in gnulib on that system,
>> doesn't it produce correct results?
> It’s not used by default.  How can I force it to be used?

Try building using './configure gl_cv_func_getaddrinfo=no'.

> (Note that I don’t have access to that machine myself, so I’m relying on
> a kind contributor.)

That always slows down things...

>>>> But it is also not clear to me that the test-case above indicate a
>>>> useful way of using getaddrinfo, what kind of application uses
>>>> parameters like that, and what result did you expect?
>>> An error, because the service name doesn’t resolve.
>> What if the system is configured (or programmed) to resolve all services
>> names?  Isn't that a valid POSIX compliant getaddrinfo implementation?
>> It's not particular useful one, I admit.
> But then a given program wouldn’t be able to do anything useful with it.
> For instance, getaddrinfo ("host", "http") would be useless if the
> resulting port were not 80, because clients elsewhere may still get 80,
> because that’s what IANA has always said.

Right.  I'm not sure how gnulib should behave here.

First, there is nothing in POSIX (I think?) that says "http" must always
resolve to port 80, and that "unknown-non-existing-service" must result
in an error.  To the contrary, getaddrinfo/getservbyname typically reads
/etc/services, which allows administrators to modify the "http" port to
something else.  So "http" is likely not even intended to be guaranteed
to translate into 80 by POSIX.  But anything but 80 is useless for
portable applications.  Should gnulib to replace a system getaddrinfo
that doesn't translate "http" to 80?

However, it seems the problem here is only about unknown service names,
for known names, and then we could apply my suggested workaround in the
second paragraph of this e-mail.


reply via email to

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