On Mon, 13 Aug 2018, myLC--- via curl-library wrote:

> With a callback you'd make sure that the user takes care of it when the data
> becomes available in that format - and only then.

Yes, but since we need to copy the entire data to the export struct, keeping
that memory around a little longer is not much harder. But of course, if done
for a lot of connections with a lot of addresses, doing the callback approach
saves notable amounts of memory. Plus the fact that if there's no callback,
there's no need to do any allocs/copies, which of course is a big plus.

A callback approach might also get away with less copying and more "pointing".

> The addrinfo structure is well documented (spares you the hassle of writing
> it up yourself;-).

1. we support platforms without it

2. we can't assume that users will find the struct somewhere else (and that it
will be sufficiently documented where found) so we still need to document it
if we use it in our API

> If you name the constant/callback after this structure, you can have a new
> one if the internal structure changes.

That could easily get annoying and require API changes too often.

Separating external and internal structs is just sensible and more likely to
keep us sane in the future.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html