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