Opened 14 years ago

Closed 14 years ago

#6200 closed bug (duplicate)

getaddrinfo() not correctly accepting some flag combinations

Reported by: anevilyak Owned by: axeld
Priority: normal Milestone: R1
Component: Kits/Network Kit Version: R1/Development
Keywords: Cc:
Blocked By: #3945 Blocking:
Platform: All

Description

Haiku's getaddrinfo() returns an error indicating invalid flags with the following sample code:

struct addrinfo *ai;
struct addrinfo hints;
memset (&hints, '\0', sizeof (hints));
hints.ai_flags = AI_PASSIVE | AI_ADDRCONFIG;
hints.ai_socktype = SOCK_STREAM;
int e = getaddrinfo (NULL, "113", &hints, &ai);

All the documentation I've read indicates that this set of flags is correct though. Removing AI_ADDRCONFIG from the flags results in normal behavior though. I suspect this is due to some hack to temporarily disable IPv6 functionality, but haven't looked more closely. The error returned was 3, which gai_strerror() indicates as being "invalid flags".

Change History (6)

comment:1 by axeld, 14 years ago

Component: System/libroot.soKits/Network Kit

Doesn't really look like it. In any case, you could easily try to revert hrev35942 which introduced ignoring IPv6 for AF_UNSPEC, and check it out.

comment:2 by anevilyak, 14 years ago

Will see what I can find hopefully sometime this week, thanks for the tip!

comment:3 by anevilyak, 14 years ago

Had a look, and it looks like a number of our AI_* defines are either bogus or out of date. Unfortunately I'm uncertain where our getaddrinfo() actually came from, though its code looks near identical to that used in FreeBSD. Our netdb.h looks quite different though as far as the AI_* defines go. Ours has AI_MASK (used to validate the flags in getaddrinfo()) hardwired to 0x00000007 for some reason, whereas FreeBSD's looks like:

#define AI_MASK \
    (AI_PASSIVE | AI_CANONNAME | AI_NUMERICHOST | AI_NUMERICSERV | \
    AI_ADDRCONFIG)

Also, some of the other AI_* values differ between us and FreeBSD's, though I'm uncertain if that's due to theirs simply being a newer revision or what. In any case, what would be the best course of action to update this, since I'm uncertain if our current libbind source is vendor branched somewhere?

comment:4 by anevilyak, 14 years ago

On second thought, maybe it's simply a case of our netdb.h being out of date? The getaddrinfo()/getnameinfo() code that we have looks like it would work correctly with the updated flag defs (assuming libbind was recompiled).

in reply to:  3 comment:5 by kaliber, 14 years ago

Replying to anevilyak:

Had a look, and it looks like a number of our AI_* defines are either bogus or out of date.

I reported that 13 months ago, see ticket #3945 ...

comment:6 by anevilyak, 14 years ago

Blocked By: 3945 added
Resolution: duplicate
Status: newclosed

Didn't see that one, thanks.

Note: See TracTickets for help on using tickets.