BIND 10 #2572: extend MasterLexer to provide current/total bytes of source(s)

BIND 10 Development do-not-reply at isc.org
Tue Jan 15 17:57:30 UTC 2013


#2572: extend MasterLexer to provide current/total bytes of source(s)
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  task          |  jinmei
            Priority:  high          |                       Status:
           Component:  libdns++      |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20130122
         Sub-Project:  DNS           |                   Resolution:
Estimated Difficulty:  4             |                 CVSS Scoring:
         Total Hours:  5.25          |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |  loadzone-ng
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Thanks for the review.

 Replying to [comment:18 muks]:

 > Here are my review comments:
 >
 > * `getStreamSize()` seems to orchestrate seeking forward and backward
 and returns either `MasterLexer::SOURCE_SIZE_UNKNOWN` or an exception
 based on where (at what step of the entire orchestration) it fails. From
 my reading, it seems that in case it is unable to seek back to the start
 of the stream, it will throw an exception which seems correct. But
 `InputSourceTest.getSize` only seems to check up to the initial `.bad()`
 and `.fail()` checks at the start of `getStreamSize()` whereas the throws
 later in that method seem important to check too. Is it possible to test
 them somehow?

 I thought about it in the original trac2572 branch and found it quite
 difficult if not impossible.  It's even difficult to make the first
 seekg() call fail reliably (so I explicitly set the fail bit in the
 test), and making other cases fail is even more difficult.  To emulate
 this situation we'd need some trick to tweak the behavior of istream
 so that the first call to seekg() succeeds but the second call fails.
 It might be possible by inheriting from some of the standard classes
 with local customization, but I'm afraid it's not only
 otherwise-discouraged practice but also has its own portability
 problems.

 So, yes, it's not good to skip some test cases but I don't have a good
 idea to test these cases reasonably.

 > * I have pushed a minor comment update commit to the branch. Please
 check it.

 These look good, thanks.

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


More information about the bind10-tickets mailing list