BIND 10 #1228: V4 packet library - option processing
BIND 10 Development
do-not-reply at isc.org
Thu Oct 27 14:05:45 UTC 2011
#1228: V4 packet library - option processing
-------------------------------------+-------------------------------------
Reporter: | Owner: tomek
stephen | Status: reviewing
Type: task | Milestone: Sprint-
Priority: major | DHCP-20111109
Component: dhcp | Resolution:
Keywords: | Sensitive: 0
Defect Severity: N/A | Sub-Project: DHCP
Feature Depending on Ticket: | Estimated Difficulty: 0
Add Hours to Ticket: 0 | Total Hours: 0
Internal?: 0 |
-------------------------------------+-------------------------------------
Changes (by stephen):
* owner: UnAssigned => tomek
Comment:
Reviewed commit bfab5a33ceabe3f0d31bd465d13308c8b84adf68
'''src/lib/dhcp/libdhcp.h'''[[BR]]
unpackOptions4 needs its own header.
Should unpackOptions4() be taking an !InputBuffer object?
packOptions - should this be called packOptions4?
'''src/lib/dhcp/libdhcp.cc'''[[BR]]
Regarding the "TODO" in unpackOptions4: Looking at this and the definition
of Option, perhaps the easiest thing would be to alter the Option
constructor to something like:
{{{
Option::Option(Universe u, uint16_t type, InputIterator first,
InputIterator last)
}}}
... and pass &buf[offet] and &buf[offset + opt_len] as the "first" and
"last" arguments.
'''src/lib/dhcp/option.h'''[[BR]]
See above comments regarding Option constructor.
'''src/lib/dhcp/option.cc'''[[BR]]
Spaces around binary operators.
pack6(): If checking an STL container for being empty, it's best to use
the empty() method. For some STL containers the time taken to perform a
size() depends on the number of elements in the container. Having said
that, for a vector, the time to perform an empty() should be about the
same as that for a size(). But I think "if (! data_.empty())" is clearer
than "if (data_.size())".
'''src/lib/dhcp/tests/libdhcp_unittest.cc'''[[BR]]
packOptions4 test: there is no need to resize a vector before adding
elements to the end of it. The use of push_back() to append an element to
the end of a vector is less error-prone.
'''src/lib/util/buffer.h'''[[BR]]
readData(): The problem here is that if the vector is too long, you end up
with a vector of which the first "len" bytes hold the data and the
remainder are junk. Also, when filling the data, an intermediate vector
is created then copied by the assignment operator. I would suggest the is
better:
{{{
data.resize(len); // Ensure vector is correct length
readData(&data[0], len); // Copy data into it using overloaded
method
}}}
--
Ticket URL: <http://bind10.isc.org/ticket/1228#comment:6>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list