BIND 10 #1783: auth could cause duplicate buffer free on exception

BIND 10 Development do-not-reply at isc.org
Mon Mar 19 17:43:01 UTC 2012


#1783: auth could cause duplicate buffer free on exception
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:         |             Milestone:
  defect                             |  Sprint-20120320
                   Priority:  high   |            Resolution:
                  Component:         |             Sensitive:  0
  b10-auth                           |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  0
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:  auth   |
  performance                        |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:5 jelte]:

 Thanks for the review.

 > Very similar to the QueryCleaner we recently added :) Is there a known
 pattern name for this? (I.E. RAII-style resetting of reusable objects,
 RAII itself doesn't seem to apply).

 I don't know of any common idiom to express this type of concept, but
 there may be one because the technique itself is pretty commonly used
 in C++.  boost names some of such classes with "scoped" (scoped_ptr,
 scoped_array, maybe some more), and I sometimes borrow that naming,
 but it doesn't seem to be the "standard" convention.

 > Perhaps we should make a naming convention for it;
 holder/cleaner/whatever. Would be a bit of a bikeshed discussion in itself
 but it would be nice to be able to immediately see the purpose of such a
 class when it is used.

 That sounds helpful.  I'm not sure if we end up having a single common
 naming convention (for example, "scope(d)" sometimes sounds natural in
 that context but is probably not always so), but at least it would
 help if we have a commonly used name for the concept (e.g. "scope
 class").

 And, about this point:

 > And when I pressed submit, I did think of one possible other change;
 perhaps the class should be public and defined with the messagerenderer
 itself. But no strong opinion on it.

 Perhaps (at least I can see the need for it in b10-resolver), although
 I personally think it would still be "project private" (so hidden in
 somewhere under "internal" namespace, and not an install target)
 rather than a real public definition.  For now, this is the only user
 of this helper so I keep it within the .cc file, but I added a note
 that we may extend it and make it more visible to other modules.

 I'm now going to merge this branch.

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


More information about the bind10-tickets mailing list