On Tue, 19 Feb 2013, Yang Tse wrote:

>> socklen_t in a public header file is potentially problematic.. there used
>> to be one in <curl/curl.h> until 7.18 I think, but it got too troublesome
>> to maintain so it got removed.
>
> When it was mentioned if ares_inet_ntop and ares_inet_ntop were to become
> fully documented or removed. I didn't realize function arguments data types
> would be modified. I know these didn't actually belong to the official
> public API, but their interfaces have been stable for more than 8 years, up
> to now.

Right. It wasn't really what I intended either! =) First it struck me that
when I made those two functions "real" members of the c-ares API I made them
unconditionally present in c-ares with those names. Previously they were just
defined macros on platforms which feature the underlying functions easily.

When I introduced them as real functions I needed actual prototypes for them,
and when I did this I got compiler warnings due to a size_t to socklen_t
conversion I then introduced.

Since these functions weren't present properly publicly in any previous
release of c-ares I decided I could just as well clean up the mess while I'm
fiddling with these functions anyway. I figured our autotests would point out
if this would be problematic, as I suspected it would but I didn't given it a
very long thought at the time I did the change.

Of course, now I need to take care of the mess I've thrown in there...

> If socklen_t is the way to go, then we should instead use ares_socklen_t,
> which has been publicly available through ares.h for more than 4 years now.

I think that's the way to go. I'll do that change now and then check back
again later to see if there's any remaining breakage due to this.

Thanks both of you!

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html