> > Perhaps a better solution would be to introduce an ipv6.h or something to
> > that effect?
>
> Would be better yes. I figure we need ot have that made public and we need
> to have configure decide what structs and defines it should include...
> Right?
Correct. So perhaps just it it in ares_ipv6.h but have ares.h include this
file?
> Hm, then we are back on providing our own structs that have all the members
> and fields we want. I don't think that is such a bad idea anyway, since
> c-ares' functions will not (and cannot) be used intermixed with other name
> resolving functions anyway. I mean, for example, passing c-ares' getaddrinfo
> results to freeaddrinfo() will never be a good idea.
Agreed. And indeed, the sockaddr_in6 I provide includes sin6_scope_id, of
course though, that's not quite as useful if the system doesn't have
if_indextoname.
> I'm more and more beginning to lean towards providing a totally separate
> name space for all these things, like prefixes with ARES or similar, to
> once and for all address these issues.
Yes, after writing that email I came to the same conclusion :) So pretty much
the way it works is instead of, say NI_NUMERICSERV we have
ARES_NI_NUMERICSERV. Then we really don't care what the OS provides.
> 5.) We still need to decide a way to return error codes. Do we want to
> implement equivalents to the various RFC3493 defined codes, or do we want
> to just have a catch-all "bad argument" code?
Unfortunately, I think you skipped over this one, and this is the one I have
the least suggestion for. To clarify what I mean, RFC3493 defines several
error codes used by getnameinfo and getaddrinfo. So lets say I specify
AF_LOCAL for the family, I'd get an EAI_FAMILY as a result. If I specified an
illegal value for the flags, I'd get EAI_BADFLAGS, or (in the case of
getaddrinfo) if I don't specify a nodename or servname, I get EAI_NONAME. The
way I've implemented it is just with ARES_EBADARG. Regardless of the precise
problem, we just return this error indicating something is wrong with the
arguments. Would you prefer it if I added a bunch of new error codes and did
it more like the standard addrinfo API?
> My opinion: start as easy as possible and note the possible improvements in
> a TODO or KNOWN_BUGS document to get worked on later.
I agree, however, I always like to place "stubs" in the code. As I'm sure you
know, when you write functions that are several hundred lines of code, then
go back and look at it a month later, you sometimes forget exactly what it
does. So, I just like to put some comments in like "/* this is where XXX goes
*/". As an example, one thing I expect will be added eventually is IDN
support (a la glibc), so I included a comment saying /* Place IDN code here
*/ just to make adding it easier later.
Btw, on the topic of known bugs, if anyone knows how NI_NOFQDN is supposed to
work exactly, please let me know. It seems every getnameinfo.c I found
implements it differently, and the RFC seems a bit ambiguous.
Dominick Meglio.
_______________________________________________
http://cool.haxx.se/mailman/listinfo/c-ares
Received on Tue Apr 12 00:08:56 2005