As discussed in zh-jq/mini-c-ares#2, I'm going to add functionalities that is required there.

The steps are:

1. Add vendored and maybe-vendored feature to c-ares and c-ares-sys.
2. Add vendored and maybe-vendored feature to c-ares-resolver.
3. Add detections in build.rs of c-ares to detect the available methods of Options, add cfgs to guard against newer APIs, and decrease the minimal supported libc-ares to 1.14.0.
4. Let c-ares-resolver export Options of c-ares directly, instead of wrap it into a new one, so we won't to do feature detection in c-ares-resolver. If we don't want the set_socket_state_callback methods exported, we may add a new UserOptions in c-ares and re-export is as Options in c-ares-resolver.
5. Expose DEP_CARES_VERSION_NUMBER env var in c-ares or c-ares-sys build.rs, and add cfgs to c-ares
6. Use DEP_CARES_VERSION_NUMBER env var in build.rs and add cfgs to c-ares-resolver

I'm going to do step 1 right now.

@dimbleby any suggestions?

Eg compare curl-sys which has a fancy build.rs. As best I can tell this looks for the required library being already installed on the system and, if not found, compiles a bundled version of the C code and links to that instead.

It all looks like quite a bit of trouble. But probably it's the done thing. Would resolve #15 too.

... when they stabilise.

Instead of mem::transmute as today

We currently have to do a bit of jumping through hoops to get from Rust IP and socket addresses to C-style in_addr, sock_addr etc.

With any luck, rust-lang/rust#27264 will go through and if so we'll be able to do this much more easily (and efficiently).

That feature is only there for the benefit of Travis CI. I've no intention of actually supporting ancient versions of c-ares.

Travis apparently intend to upgrade to a modern environment - per travis-ci/travis-ci#2046. Remove old-cares when this happens.

Write documentation

We currently resort to #[doc = "blah"], because plain old comments are mis-parsed and show up with a leading '///' in the rustdoc.

It looks as though rust-lang/rust#27056 should fix this, so when that hits stable Rust we can tidy up.

As well as adding new examples for new query types, should have:

• an example where we set the event loop running and then submit queries
• an example not using a full-blown event loop (via ares_getsock)

... and possibly more.

Purpose being both to provide examples, and also to verify that we have a usable API

thread '' panicked at 'index 34 out of range for slice of length 32', /root/.cargo/registry/src/github.com-1ecc6299db9ec823/c-ares-7.2.0/src/a.rs:54:23

it seems that c_ares_sys::ares_parse_a_reply may return more than MAX_ADDRTTLS records.

Could you make sure the build script export headers file. I wanted to make a PR but I think the repo is in a broken state. It does not build for me.

Related: alexcrichton/curl-rust#427

This issue was automatically generated. Feel free to close without ceremony if
you do not agree with re-licensing or if it is not possible for other reasons.
Respond to @cmr with any questions or concerns, or pop over to
#rust-offtopic on IRC to discuss.

You're receiving this because someone (perhaps the project maintainer)
published a crates.io package with the license as "MIT" xor "Apache-2.0" and
the repository field pointing here.

TL;DR the Rust ecosystem is largely Apache-2.0. Being available under that
license is good for interoperation. The MIT license as an add-on can be nice
for GPLv2 projects to use your code.

Why?

The MIT license requires reproducing countless copies of the same copyright
header with different names in the copyright field, for every MIT library in
use. The Apache license does not have this drawback. However, this is not the
primary motivation for me creating these issues. The Apache license also has
protections from patent trolls and an explicit contribution licensing clause.
However, the Apache license is incompatible with GPLv2. This is why Rust is
dual-licensed as MIT/Apache (the "primary" license being Apache, MIT only for
GPLv2 compat), and doing so would be wise for this project. This also makes
this crate suitable for inclusion and unrestricted sharing in the Rust
standard distribution and other projects using dual MIT/Apache, such as my
personal ulterior motive, the Robigalia project.

Some ask, "Does this really apply to binary redistributions? Does MIT really
require reproducing the whole thing?" I'm not a lawyer, and I can't give legal
advice, but some Google Android apps include open source attributions using
this interpretation. Others also agree with
it.
But, again, the copyright notice redistribution is not the primary motivation
for the dual-licensing. It's stronger protections to licensees and better
interoperation with the wider Rust ecosystem.

How?

To do this, get explicit approval from each contributor of copyrightable work
(as not all contributions qualify for copyright, due to not being a "creative
work", e.g. a typo fix) and then add the following to your README:

## License

Licensed under either of

 * Apache License, Version 2.0 ([LICENSE-APACHE](LICENSE-APACHE) or http://www.apache.org/licenses/LICENSE-2.0)
 * MIT license ([LICENSE-MIT](LICENSE-MIT) or http://opensource.org/licenses/MIT)

at your option.

### Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted
for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any
additional terms or conditions.

and in your license headers, if you have them, use the following boilerplate
(based on that used in Rust):

// Copyright 2016 rust-c-ares developers
//
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
// option. This file may not be copied, modified, or distributed
// except according to those terms.

It's commonly asked whether license headers are required. I'm not comfortable
making an official recommendation either way, but the Apache license
recommends it in their appendix on how to use the license.

Be sure to add the relevant LICENSE-{MIT,APACHE} files. You can copy these
from the Rust repo for a plain-text
version.

And don't forget to update the license metadata in your Cargo.toml to:

license = "MIT/Apache-2.0"

I'll be going through projects which agree to be relicensed and have approval
by the necessary contributors and doing this changes, so feel free to leave
the heavy lifting to me!

Contributor checkoff

To agree to relicensing, comment with :

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.

Or, if you're a contributor, you can check the box in this repo next to your
name. My scripts will pick this exact phrase up and check your checkbox, but
I'll come through and manually review this issue later as well.

• @dimbleby
• @CJTozer

Currently cross compiling this crate doesn't work, I think because of the way it configures the build of c-ares.

I've tried building for armv7-linux-androideabi on linux and the *-apple-ios targets from MacOs.

Values are currently hardcoded.

api.apaylater.com has CNAME prod_api.apaylater.com which is considered invalid since c-ares 1.17.2, and this was fixed in c-ares commit.
Please backport this patch to the vendored c-ares-sys code, and publish a fixed version.
Thanks

... when the wrapper is more complete, and the API has stabilized.

Implement more query types - SRV, CNAME, MX, etc

Would you consider reverting to 2018 edition? I made a PR on curl-rust to use this crate and there is some concern about that. See alexcrichton/curl-rust#427

This was fixed in c-ares in c-ares/c-ares@a788a1a, so it looks like rust-c-ares is just using a too-old version.

Not currently stable, so can't use them yet anyway.

But if I understand correctly, our XXXResults types would be a good use case for Unique<c-ares-structure>, rather than the current*mut c-ares-structure

The example in cares_futures.rs currently has queries returning BoxFuture. That's an unnecessary allocation best avoided by returning impl Future - if and when that stabilises.

See rust-lang/rust#34511.

While the API has been changing rapidly and the coverage of c-ares was incomplete, it made perfect sense for the README to warn "Work in progress. Use with extreme caution."

However, we've now wrapped most (maybe all?) of the c-ares function that I intend to wrap; and right now I don't have any plans to break the current interfaces.

If that continues to hold for a few days, let's put some more detail in the README - and remove the warning.

I'd assumed that the answer was always the same as the question, but apparently not - there seems to be an implicit CNAME lookup going on.

Expected approach:

• introduce AResult<'a> which contains both IPv4Addr and &'a str
• iterator obtained from AResults return these instead of IPv4Addrs

(Likewise for AAAA lookups).

Lots of code in the examples that goes blah().ok().expect(). WIBNI to remove the intermediate ok().

rust-lang/rust#27277

Not a priority, but a long term goal.

Exposed interface currently use std::os::unix::io::RawFd so would need to wrap that in some way.

Examples using mio won't work until mio supports Windows.

Perhaps we just wait to see how mio ends up supporting Windows and then do something similar here.

... once std::net::IpAddr stabilizes.

Running cares-resolver example, A lookup returns fine, AAAA lookup hangs.

Checking with dig, I get:

$ dig -6 google.com

; <<>> DiG 9.9.4-RedHat-9.9.4-18.el7_1.1 <<>> -6 google.com
;; global options: +cmd
;; connection timed out; no servers could be reached

...so I'd expect a timeout and failure in the example too.