BIND 10 #703: Testing resolver with bad packets

[BIND 10 Development]

#703: Testing resolver with bad packets
-------------------------------------+-------------------------------------
                 Reporter:  stephen  |                Owner:  stephen
                     Type:           |               Status:  reviewing
  enhancement                        |            Milestone:
                 Priority:  major    |  Sprint-20110419
                Component:           |           Resolution:
  Unclassified                       |            Sensitive:  0
                 Keywords:           |  Add Hours to Ticket:  0
Estimated Number of Hours:  8.0      |          Total Hours:  0
                Billable?:  1        |
                Internal?:  0        |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => stephen


Comment:

 Hello

 First of all, I bow to your incredible typing skills. To write enough code
 so it presents me with 6k lines of patches in a day, it's something to be
 proud of ;-).

 Replying to [comment:7 stephen]:
 > > Did you run it against the server? Everything OK?
 > Duh!  I was so focused on getting the code into a state where it could
 be included in the distribution, I omitted to report on the tests. I've
 run the current version of the program against the current development
 version of the resolver - the results are in the
 [attachment:BadPacketTests_2011-04-13.txt attachment] to this ticket.  In
 summary, the resolver passed the tests, although I do have a question as
 to the rcode returned when a NOTIFY message is received.

 ACK.

 > > There are tests for the code, so I guess this is something we want to
 distribute as a tool for people to use.
 > No - all code should be tested, even if we aren't distributing it.
 Whether we want this as a fully-supported tool is something that needs to
 be discussed.

 Well, that would be really hard, if all test code would have to be tested
 as well, we would need to write a valid test code that could test
 something else and itself as well. It probably could be proven such code
 exists, but I think we have an exception that test code doesn't have to be
 tested ;-). Of course, testing some of it voluntarily isn't a problem.

 > > Did we talk about getopt_long? I don't really remember, but is it
 available everywhere?
 > The last time I looked I it was, although on one system the calling
 sequence is different (there is an additional argument).  I thought that
 this was Solaris but that's not the case - the code built on Solaris, OS X
 and FreeBSD.  In this case getopt_long is needed because there are so many
 cryptic options, so if the build fails I'll add an #ifdef for that
 operating system.

 I see. It's not a problem with a test program.

 > > This isn't very helpful (I can parse it, but some friendlier error
 wouldn't hurt):
 > The bad lexical cast exception is now intercepted and a more friendly
 message is output.

 Well, the unhelpful text of the what() was part of it, but you seem to
 rely on the fact that the exception is printed automatically. But it isn't
 so much a problem I guess, if it will be only us running it.

 I noticed you used the enum as a parameter, but went for int in some later
 version. Why?

 And, is it allowed by standard to have multiple enum elements with the
 same numerical value? Isn't it just that gcc is benevolent?

 With regards

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