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