BIND 10 #703: Testing resolver with bad packets

[BIND 10 Development]

#703: Testing resolver with bad packets
-------------------------------------+-------------------------------------
                 Reporter:  stephen  |                Owner:  vorner
                     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 stephen):

 * owner:  stephen => vorner


Comment:

 > 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.
 The code does rely on getopt_long() printing the option in error because
 the loop that interprets the options only receives a '?' in the case of an
 unrecognised option.  (In this case the code terminates by throwing an
 exception derived from isc::Exception which, like all such exceptions in
 this program, is caught (and printed) in main().)

 > I noticed you used the enum as a parameter, but went for int in some
 later version. Why?
 The code was changed to use arrays and the elements of the enum are now
 used to name specific indexes in those arrays. Also declared in the enum
 is a variable denoting the size of the arrays.  So the enum is really
 being used as a convenient way of declaring integer constants.  This was
 reinforced by a change to the code that involves iterating through the
 arrays; the index element in these cases is an int.  As there as there is
 no default conversion between an "int" and an element of an "enum", the
 compiler was generating errors when the index was passed to a method
 expecting an enum.  So the decision was made to move to int's.

 Of course, it would have been possible to provide an explicit cast between
 int and the enum.  An alternative would have been to overload operator++()
 etc. to provide iterator-like behaviour to variables of that type.  But
 this would have required additional work and it was judged just not to be
 worth it for the gain.


 > And, is it allowed by standard to have multiple enum elements with the
 same numerical value? Isn't it just that gcc is benevolent?
 I've not found mention of any restriction.  If there turns out to be, it
 would be trivial to define another enum containing the synonyms.

 BTW, the intended !ChangeLog entry is:
 {{{
   XXX.  [func]          stephen
         Added the 'badpacket' program for testing which sends a set of
         (potentially) bad packets to a nameserver and prints the
 responses.
         (Trac #703, git yyyyy...)
 }}}

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