bug-gnulib
[Top][All Lists]
Advanced

[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




reply via email to

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