BIND 10 #1186: libdhcp implementation - DHCPv6 part

BIND 10 Development do-not-reply at isc.org
Thu Oct 13 13:14:14 UTC 2011


#1186: libdhcp implementation - DHCPv6 part
-------------------------------------+-------------------------------------
                   Reporter:  tomek  |                 Owner:  stephen
                       Type:         |                Status:  reviewing
  enhancement                        |             Milestone:  Sprint-
                   Priority:  major  |  DHCP-20111026
                  Component:  dhcp   |            Resolution:
                   Keywords:         |             Sensitive:  0
            Defect Severity:  N/A    |           Sub-Project:  DHCP
Feature Depending on Ticket:  878    |  Estimated Difficulty:  0
        Add Hours to Ticket:  0      |           Total Hours:  0
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by stephen):

 Replying to [comment:9 tomek]:
 '''src/lib/dhcp/option.h'''[[BR]]
 >> addOption(): shared pointer should be passed by reference (to avoid a
 needless copy when passed by value).
 > Certainly not. That is where copy or shared pointer is needed. One
 option (e.g. server-id) may be added in many places, yet due to shared
 pointer only one instance will be created.
 I think you misunderstood the comment.  The idea is that the shared_ptr
 object is passed by reference, not the pointed-to object.  This avoids a
 copy being made of the pointer object when it is passed into the method.

 As it is, the pointer object is copied when it is passed to the method,
 the copy is itself copied when the pair() argument to insert() is
 constructed.  A quick check shows that in the call to insert, a further
 two copies are made of the pointer object, one of which is destroyed when
 the insert() call returns.  And when the call to addOption() returns, the
 copy created for the pair() and the copy created by the call-by-value are
 destroyed.

 In all these copies, there is only ever one instance of the underlying
 object. Passing the argument by reference eliminates one of the pointer
 object copies (and destructor calls).

 This comment applies to a number of methods where a shared_ptr is passed
 by value.

 '''src/lib/dhcp/option.cc'''[[BR]]
 >> pack6()/pack6(): use of an OutputBuffer will automatically take care of
 extending the buffer as needed.
 > Calling realloc() many times is less optimal than calculating length and
 then doing a single new (Pkt6 approach).
 !OutputBuffer can be created with an initial length. If that is exceeded,
 then it grows automatically.  The idea is that (a) the buffer is
 encapsulated and provides methods for writing variable length data items
 to it and (b) if code is changed such that the initial buffer allocation
 is incorrect, it doesn't cause a problem.

 '''src/lib/dhcp/option6_addrlst.h'''[[BR]]
 >> In the constructor for parsing the received option (and in both pack()
 and unpack()), "buf" should be passed by reference.
 > No. This buffer should be kept around for until this option is valid.
 Passing shared pointer be reference is valid only for pure consumers. That
 is clearly not the case here.
 As noted above, passing the shared_ptr object by merely eliminates a copy
 of the pointer object, it does not affect the underlying pointed-to data.
 The pointer is not being altered in this method, it is just being used to
 access the pointed-to data.

 One other thing:

 pack(): C++-style casts should be used (in this case it would be a
 reinterpret_cast<uint16_t*>()).  However, even better would be to use the
 writeUint16 function in io_utilities.h which would eliminate the need for
 a cast.

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


More information about the bind10-tickets mailing list