BIND 10 #2384: extend RRTTL "from text" constructor so it can accpet 1H, 2D, etc.

[BIND 10 Development]

#2384: extend RRTTL "from text" constructor so it can accpet 1H, 2D, etc.
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20121120
  medium                             |            Resolution:
                  Component:         |             Sensitive:  0
  libdns++                           |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  4
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
  loadzone-ng                        |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 The revised version looks mostly okay, but I believe we need one
 additional check here:

 {{{#!cpp
             // Check the partial value is still in range (the value can
 only
             // grow, so if we get out of range now, it won't get better,
 so
             // there's no need to continue).
             if (value < 0 || val < 0 || val > 0xffffffff) {
                 isc_throw(InvalidRRTTL, "Part of TTL out of range: " <<
                           ttlstr);
             }
 }}}

 We should confirm 'value < 0xffffffff' too, otherwise it would accept
 something like this: "256S307445734561825856M".  I'm attaching a
 suggested patch.  If you're okay with, please apply it and merge.

 > Replying to [comment:9 jinmei]:

 > > - Also, is `unit - pos` safe?  `operator-` only works for random
 > >   access iterators, and (in my understanding) we cannot assume the
 > >   type of string iterators.
 >
 > It is not used any more. But I think it is. The string has `operator[]`
 and
 > `cstr()`, which both indicate string is random-accessible and the
 internal
 > representation is just a block of memory. These are just hints, I'm not
 sure it
 > is actually mandated explicitly.

 Hmm, C++2003 standard says the string iterator is a random access
 iterator, so I was wrong here.  (although I don't think the existence
 of operator[], etc immediately supports the fact - consider,
 for example, std::map::operator[], and the complexity for operator[]
 isn't guaranteed for string, unlike vector).

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