BIND 10 #2095: Define and implement RdataEncoder class
BIND 10 Development
do-not-reply at isc.org
Tue Jul 31 08:56:17 UTC 2012
#2095: Define and implement RdataEncoder class
-------------------------------------+-------------------------------------
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: 5
Defect Severity: N/A | Total Hours: 2.96
Feature Depending on Ticket: |
scalable inmemory |
Add Hours to Ticket: 0 |
Internal?: 0 |
-------------------------------------+-------------------------------------
Changes (by vorner):
* totalhours: 0 => 2.96
Comment:
Replying to [comment:13 jinmei]:
> Replying to [comment:12 vorner]:
> > * The code in `updateOtherData` is confusing. I'm not really sure how
to improve that, maybe placing the variable length thing into an else
branch instead of using continue could be an option.
>
> I agree it's not very understandable. In fact I didn't really like
> that implementation either. On closer look I found it could be much
> more simplified, and I did it at commit 8560883.
It is much better now. However, there some problems introduced here:
{{{#!c++
/// <0 or more fixed/var-len data fields>,
/// <0 or more domain name fields>,
/// <0 or more fixed/var-len data fields>,
/// <0 or more domain name fields>,
}}}
I don't think this is accurate. There is 0 or 1 data fields. And there's
always 1 or more name fields.
Also, here:
{{{#!c++
// Then, we still have a field in the spec, and it must be a
domain
// name field. Since we know we've passed any prior data field,
the
// next field must be a domain name as long as it exists;
otherwise
// it's a bug in the spec (not a bogus input). So we assert()
that
// condition.
if (current_field_ >= encode_spec_->field_count) {
isc_throw(BadValue,
"RDATA encoder encounters an unexpected name data: "
<<
name);
}
}}}
The comment talks about assert, but I see none. Also, the comment looks
slightly repetitive to me?
> > Also, I'd like to see the thing does not go outside the buffer that is
passed to it. Would it be possible to do a test with a canary vale after
the data and see it survived?
>
> you mean as a result of encode()? I think the assert() check would
> catch any such bugs, but I've added some explicit check in the
> unittests with canary data (commit 84e7463).
It's funny to see you placing an already `dead` canary there, but
otherwise OK.
So, except for the comments, I think it can be merged.
--
Ticket URL: <http://bind10.isc.org/ticket/2095#comment:15>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list