BIND 10 #2092: RBNode parent pointer updates

BIND 10 Development do-not-reply at isc.org
Thu Jul 26 06:33:19 UTC 2012


#2092: RBNode parent pointer updates
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  vorner
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20120731
  medium                             |            Resolution:
                  Component:  data   |             Sensitive:  0
  source                             |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  4
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
  scalable inmemory                  |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by muks):

 * owner:  muks => vorner


Comment:

 Hi vorner

 Replying to [comment:15 jinmei]:
 > The code looks mostly OK, but:
 >  * The rebasing is not good for reviewing. Since rebasing could have
 changed (or you, because of the conflicts) the old commits, I needed to
 review the whole thing once again.

 I am very sorry. I'll do merges from now on. In this particular case, the
 commits are still identical to the last ones (if that is any consolation).

 >  * Inspired by what Jinmei mentioned yesterday in Jabber, this (and
 similar ones) looks unsafe:
 > {{{#!c++
 > if (parent == parent->getParent()->getLeft())
 > }}}
 >    The code checks only that the node is not root, so the parent can be.
 And it could be the root of the top-most tree, in which case the parent
 would be NULL. So parent->getParent() would return NULL and the getLeft
 would segfault. I think this is one of the places where the code assumed
 the link-to-self property of the sentinel.

 In our trees, root is always black. So the dereference will always work.

-- 
Ticket URL: <http://bind10.isc.org/ticket/2092#comment:17>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development


More information about the bind10-tickets mailing list