Subject: Re: IPv6 Issues

Re: IPv6 Issues

From: Daniel Stenberg <daniel_at_haxx.se>
Date: 2005-04-12

On Mon, 11 Apr 2005 codemstr@ptd.net wrote:

>> 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.

Exactly. I think this is the only way to keep us sane! ;-)

>> 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?

I think having separate error codes is better, but I don't think it is worth
bending over backwards to support it.

>> 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.

Yes, that is of course a good thing. Comments in general is a good thing to
make it easier to get back to the code later on, or to allow others to
understand your way of thinking.

> 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.

RFC3493 defines it as:

    - If the flag bit NI_NOFQDN is set, only the node name portion of
       the FQDN shall be returned for local hosts.

I've never used it myself and I'm really not that experienced in DNS internals
to say anything else than this! ;-)

-- 
   c-ares -- my preferred DNS asynch resolver library
_______________________________________________
http://cool.haxx.se/mailman/listinfo/c-ares
Received on Tue Apr 12 10:48:53 2005