BIND 10 #703: Testing resolver with bad packets

[BIND 10 Development]

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


Comment:

 Hello

 Replying to [comment:9 stephen]:
 > > 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().)

 Ah, sorry, I seem to have overlooked the try-catch in the main and though
 it's the automatic output of uncaught exception.

 > 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.

 Crap, yes, I see, the ++ doesn't work on them in C++. It must have been C,
 where I used a for cycle to iterate over enum. Anyway, never mind.

 > > 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.

 OK. It just looked suspicious.

 > 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...)
 > }}}

 OK.

 So, please merge.

 Thanks

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