[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: |
Tue, 16 Feb 2010 18:28:16 +0100 |
User-agent: |
Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) |
address@hidden (Ludovic Courtès) writes:
> Hello!
>
> The getaddrinfo(3) function appears to have bogus behavior on
> ‘i386-apple-darwin9.2.2’ (Darwin 9.6 apparently doesn’t have the
> problem). Here’s the test program:
>
> #include <netdb.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
>
> int
> main (int argc, char *argv[])
> {
> int err;
> struct addrinfo *res, hints;
>
> memset (&hints, 0, sizeof (hints));
> err = getaddrinfo (NULL, "does-not-exist", &hints, &res);
> printf ("err = %i `%s'\n", err, gai_strerror (err));
>
> return err != 0 ? EXIT_SUCCESS : EXIT_FAILURE;
> }
>
> Here, I’d expect either ‘EAI_NONAME’ or ‘EAI_SERVICE’ (glibc 2.11
> returns the latter on GNU/Linux). On ‘i386-apple-darwin9.2.2’ it
> succeeds:
>
> err = 0 `Unknown error'
>
> My guess is that it’s a bug. What do you think?
I'm not sure, what exactly makes you believe that other than that there
is a mismatch between the glibc behaviour?
According to
http://www.opengroup.org/onlinepubs/9699919799/functions/getaddrinfo.html
a NULL nodename:
If nodename is not null, the requested service location is named by
nodename; otherwise, the requested service location is local to the
caller.
Which I confess I don't fully understand, but might mean undefined. It
also says:
If the ai_family field to which hints points has the value AF_UNSPEC,
addresses shall be returned for use with any address family that can
be used with the specified nodename and/or servname.
Which makes me curious about what data is in the returned 'res' variable
above. Could you print it? See tests/test-getaddrinfo.c for printing
code.
> 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.
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?
The nature of name-lookups is always a bit undefined, because one name
may exist on one system and not on another.
/Simon
Re: Bogus getaddrinfo(3) on Darwin 9.2.2, Ludovic Courtès, 2010/02/16
Re: Bogus getaddrinfo(3) on Darwin 9.2.2, Paolo Bonzini, 2010/02/17