BIND 10 #2442: update TXTLikeImpl with from lexer constructor

[BIND 10 Development]

#2442: update TXTLikeImpl with from lexer constructor
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  task          |  vorner
            Priority:  medium        |                       Status:
           Component:  libdns++      |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20121218
         Sub-Project:  DNS           |                   Resolution:
Estimated Difficulty:  4             |                 CVSS Scoring:
         Total Hours:  0             |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |  loadzone-ng
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:8 vorner]:

 > In the `decimalToNumber` function, wouldn't it be easier to construct a
 std::string in-place with begin and end iterator form instead of the
 several lines of memcpy juggling?

 (not clearly remember any more but) I guess I wanted to avoid the
 construction overhead for std::string.  But, on second thought, that
 may be a premature optimization, and even if memcpy is notably faster,
 \DDD handling should be a pretty rare case.  Using std::string is
 certainly more concise and understandable, so I revised the code that
 way.

 > I believe the reported message should have the `-1` adjustment here too:
 > {{{#!c++
 >     if (result.size() > MAX_CHARSTRING_LEN + 1) { // '+ 1' due to the
 len field
 >         isc_throw(CharStringTooLong, "character-string is too long: " <<
 >                   result.size() << " bytes");
 >     }
 > }}}

 I think it's a matter of interpretation, and while I don't necessarily
 oppose to that, the current interpretation seems to be closer to what
 the RFC states:

 {{{
 <character-string> is a single
 length octet followed by that number of characters.  <character-string>
 is treated as binary information, and can be up to 256 characters in
 length (including the length octet).
 }}}

 > Is it obvious why this works? Or is it guaranteed from the string
 implementation?
 > {{{
 > region.beg = &str[0];       // note this works even if str is empty ‒
 hmm, what does it guarantee?
 > }}}

 It's guaranteed by the C++ standard library specification.  According
 to the ISO C++ 2003 spec:

 {{{
 21.3.4 basic_string element access
 const_reference operator[](size_type pos) const;
 reference operator[](size_type pos);
  Returns: If pos < size(), returns data()[pos]. Otherwise, if pos ==
  size(), the const version returns charT(). Otherwise, the behavior is
 undefined.
 }}}

 I've updated the comment to clarify that a bit.

 This may be a less known behavior, but I'm afraid alternatives would
 make it less readable (`MasterToken::StringRegion::beg` is guaranteed
 to be non NULL, so we'd need some dummy pointer if we want to treat
 the case of empty string separately).

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