BIND 10 #487: Handle query response from authoritative server
BIND 10 Development
do-not-reply at isc.org
Mon Jan 24 14:41:56 UTC 2011
#487: Handle query response from authoritative server
-------------------------------------+-------------------------------------
Reporter: shane | Owner: jelte
Type: | Status: reviewing
enhancement | Milestone: R-Team-
Priority: major | Sprint-20110125
Component: | Resolution:
resolver | Sensitive: 0
Keywords: | Add Hours to Ticket: 0
Estimated Number of Hours: 3.0 | Total Hours: 0
Billable?: 1 |
Internal?: 0 |
-------------------------------------+-------------------------------------
Changes (by stephen):
* owner: stephen => jelte
Comment:
Updated to revision 344dcf64d70d10d47d405b4e88e3cefca777aa6
> response_classifier.cc:234 according to the coding style guidelines (in
this case the one from bind9) the ternary operator
> for a return value is a nono
Changed (and also changed the other occurrence in the file).
Do we want to revisit this for BIND-10? Although I can see cases where it
can be abused, IMHO
{{{
return (<bool-or-simple-expression> ? <value1> : <value2>);
}}}
is clearer and easier to read than
{{{
if (<bool-or-simple-expression>) {
return (<value1>);
} else {
return (<value2>);
}
}}}
> I am wondering if we should differentiate between a 'normal' ANSWER
result and a CNAME-but-answer one (behaviour
> of the caller on both cases should be the same, but still)
Done. Added the return category ANSWERCNAME, which is returned when a
CNAME chain has been followed to get the answer.
Since the number of error returns is relatively large, I've also added
"ResponseClassifier::error()" to quickly determine whether a return code
is a success or error.
> question.h contains a bit of garbage on line 191
Removed.
> question_unittests: I know this isn't done in the existing tests here,
but shouldn't we use EXPECT_EQ and EXPECT_NE instead of EXPECT_TRUE(a ==
b) etc?
I've left them as is, because these are multiple tests that operator==()
and operator!=() work. (So the tests check (for example) that both A==B is
true and A!=B is false; with EXPECT_EQ/NE we can only check that either
A==B or A!=B for any condition.) I would tend to use EXPECT_EQ/NE for the
case where we are checking some other function and implicitly assume that
both "operator==()" and "operator!=()" work.
'''Notes'''[[BR]]
I've also added one additional check; the function now detects mixed
QNAMES earlier if the QTYPE is ANY.
--
Ticket URL: <http://bind10.isc.org/ticket/487#comment:5>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list