daviddrysdale / c-ares / 253 / 3
89%
master: 89%

DEFAULT BRANCH: master
Ran
Files 252
Run time 10s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 95.421% (+0.05%) from 95.37%
BUILD_TYPE=coverage

push

travis-ci

daviddrysdale 
api: add ARES_OPT_NOROTATE optmask value

Fix up a couple of problems with configuring whether c-ares rotates
between different name servers between requests.

Firstly, ares_save_options() returns (in *optmask) the value of
(channel->optmask & ARES_OPT_ROTATE), which doesn't necessarily
indicate whether the channel is or is not actually doing rotation.
This can be confusing/incorrect if:
 - the channel was originally configured without ARES_OPT_ROTATE
   (so it appears that the channel is not rotating)
 - the /etc/resolv.conf file includes the 'rotate' option
   (so the channel is actually performing rotation).

Secondly, it is not possible to reliably configure a channel
to not-rotate; leaving off ARES_OPT_ROTATE is not enough, since
a 'rotate' option in /etc/resolv.conf will turn it on again.

Therefore:
 - add an ARES_OPT_NOROTATE optmask value to allow explicit
   configuration of no-rotate behaviour
 - in ares_save_options(), report the value of channel->rotate
   as exactly one of (optmask & ARES_OPT_ROTATE) or
   (optmask & ARES_OPT_NOROTATE).

In terms of back-compatibility:
 - existing apps that set ARES_OPT_ROTATE will continue to rotate,
   and to have ARES_OPT_ROTATE reported back from ares_save_options()
 - existing apps that don't set ARES_OPT_ROTATE will continue to
   use local config/defaults to decide whether to rotate, and will
   now get ARES_OPT_ROTATE or ARES_OPT_NOROTATE reported back from
   ares_save_options() rather than 0.

3605 of 3778 relevant lines covered (95.42%)

3684.82 hits per line

Source Files on job 253.3 (BUILD_TYPE=coverage)