BIND 10 #2086: allow construct LabelSequence from "raw data"

BIND 10 Development do-not-reply at isc.org
Sat Jun 30 06:48:04 UTC 2012


#2086: allow construct LabelSequence from "raw data"
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  UnAssigned
  jinmei                             |                Status:  new
                       Type:  task   |             Milestone:  Next-Sprint-
                   Priority:         |  Proposed
  medium                             |            Resolution:
                  Component:         |             Sensitive:  0
  libdns++                           |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  0
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
  scalable inmemory                  |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Description changed by jinmei:

Old description:

> i.e. sets of const uint8_t* data (for name data and offsets).
>
> We first need to make this class free from Name object (so directly
> holding a uint8_t*  of name data and offsets).  Then add another
> constructor to make this ticket possible.
>
> One open question is how much we should validate its input.  basically
> the data should originally come from another LabelSequence and should
> be valid.  But it's not guaranteed by the interface, so it should be
> generally validated.  But it could be expensive in the intended usage
> of it - we should consider the tradeoff.

New description:

 i.e. sets of const uint8_t* data (for name data and offsets).

 We first need to make this class free from Name object (so directly
 holding a uint8_t*  of name data and offsets).  Also make sure this
 version of constructor "explicit" (implicit conversion from `Name` to
 `LabelSequence` can be really confusing).

 Then add another constructor to make this ticket possible.

 One open question is how much we should validate its input.  basically
 the data should originally come from another LabelSequence and should
 be valid.  But it's not guaranteed by the interface, so it should be
 generally validated.  But it could be expensive in the intended usage
 of it - we should consider the tradeoff.

--

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


More information about the bind10-tickets mailing list