No need to depend on the rest of the test code (ares-test.h) for
the fuzzer entrypoint; this makes the entrypoint slightly simpler
to build with LLVM's libFuzzer.
Also shift the code to effectively be C rather than C++
The test binary built in the MinGW build is failing for some
reason. It works for me when I build locally, so I'm guessing
it's down to some sort of AppVeyor environment issue.
Disable for now.
Add a test script that runs the fuzzing command over the
corpus of DNS packets. This doesn't actually do any fuzzing
(it just runs them as inputs without generating any variations)
but it does ensure that the fuzzing entrypoint is still working.
For fuzz testing it is useful to start from a corpus of valid
packets, so fill out the test/fuzzinput/ directory with a bunch
of inputs.
These packets were generated by temporarily modifying the c-ares
process_answer() function to save off any incoming response messages.
On a build where MSAN has been manually set up (which involves
using an MSAN-instrumented version of the standard C++ library, see
https://github.com/google/sanitizers/wiki/MemorySanitizerLibcxxHowTo)
there's a warning about use of uninitialized memory here. It
might be a false positive, but the fix is trivial so include it.
The current approach for disabling tests is not a good solution because
it forces you to pass --disable-tests, rather than auto-detect if your
system can support the tests in the first place. Many (most?) systems
do not have C++11. This also causes issues when chain-building c-ares,
the hosting system needs to be updated to support passing this
additional flag if necessary, it doesn't seem reasonable to add this
requirement which breaks compatibility.
This change auto-detects if the system can build the tests and
automatically disable them if it cannot. If you pass --enable-tests to
configure and the system cannot build them either due to lack of system
support, or because cross-compilation is being used, it will throw an
appropriate error since the user indicated they really did want the
tests.
For UDP tests, there's a chance of a retry. EXPECT_CALL only
expects a single request to arrive at the server; ON_CALL allows
for a UDP retry and repeats the same answer.
Note that ON_CALL and EXPECT_CALL can't be mixed in the same
test, and that tests that have a varied sequence of responses
for the same repeated request still have to use EXPECT_CALL.