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.
Modern Linux systems may have libnss_resolve from systemd as the
resolver, which is then configured in /etc/nsswitch.conf with
the "resolve" keyword rather than "dns".
Fixes#33
After 46bb820be3 `init_by_resolv_conf`
errors are no longer swallowed in `ares_init_options`. This has exposed
a previously unknown bug in `lookups` initialization code.
If there is no lookup configuration in `resolv.conf`,
`init_by_resolv_conf` will attempt to read it from other files available
on the system. However, some of these files may have restricted
permissions (like `600`), which will lead to `EACCESS` errno, which in
turn is handled like a fatal error by `init_by_resolv_conf`.
However, it sounds illogical that this error should be handled as a
fatal. There is a `init_by_defaults` call that overrides `lookups` with
default value, and certainly possible absence of lookup information is
the reason why this function exists in a first place!
I suggest handling any `fopen` errors as non-fatal ones, allowing to
pick up the `lookups` value from different config files, or to pick up
default value.
This function sets a callback that is invoked after the socket is
created, but before the connection is established. This is an ideal
time to customize various socket options.
Introduce `ares_txt_ext` structure with an extra `record_start`
field, which indicates a start of a new TXT record, thus allowing to
differentiate the chunks in the same record, from a chunks in a
different record.
Introduce a new API method: `ares_parse_txt_reply_ext` that works with
this kind of struct.
Aim is to ensure that code coverage information can escape the
container. To do this:
- Enter a new mount namespace too, so that we can...
- Bind mount the expected source directory into the container
- Share memory with the sub-process so coverage information is
shared too.
On Linux we can potentially use user and UTS namespaces to run a test
in a pseudo-container with:
- arbitrary filesystem (e.g. /etc/resolv.conf, /etc/nsswitch.conf, /etc/hosts)
- arbitrary hostname/domainname.
Include a first pass at the framework code to allow this, along with a
first test case that uses the container.
