Re: c-ares API vs c-ares source code provided functions (Win32 recommended reading)

2009/11/3, Daniel Stenberg wrote:

> On Tue, 3 Nov 2009, Yang Tse wrote:
>
> > ares_inet_net_pton, ares_inet_ntop, ares_inet_pton, ares_strcasecmp,
> ares_strncasecmp and ares_getopt.
> >
>
> What apps need/want these functions then? I mean, if we just decide to not
> provide them to the outside world, who will be sad?

I don't have that information, but affected users would be in the
Win32 DLL camp.

Avira folks reading the mailing list?

Unless others speak up, we won't have a clue relative to if these
functions are actually being used or not by other programs than the
three c-ares sample ones. Except for ares_inet_net_pton the other ones
are used by the three samples.
.
> The ares_getopt is only used by the demo/test apps afaik, so we could view
> that as just that: demo code.

Yep, and using it as "source code provided" is quite clean.

> > Conditional c-ares API or c-ares source code provided functions?
> >
>
> Isn't there also the option of making them part of the unconditional API?
> I'm hesitant to make the API conditional and providing these functions as
> "source code provided" will be messy.

Yes, of course, there's also the option of adding them unconditionally
to the c-ares API, probably ares_inet_ntop and ares_inet_pton deserve
that 'honor', I'm not so sure the other ones do.

But either way I have no strong position on either side.

-- 
-=[Yang]=-