[Bill Meier <wmeier@xxxxxxxxxxx>]

After adding a little validation code to dissector_add I've found that 
there are currently at least two cases where multiple dissectors are 
registered to the same non-zero tcp or udp port:
=====
udp.port: dsctr: cpfi;     key  5000 already registered to: airopeek
udp.port: ddctr: tapa;     key  5000 already registered to: cpfi

result:
  cpfi & airopeak registrations lost (as well as a little memory leak)

=====
tcp.port: dsctr: tcpencap; key 10000 already registered to: ndmp

result:
  ndmp registration lost ....


----------------------

Q1: Can anyone suggest the appropriate resolution of these conflicts ?

Q2: It seems reasonable to me to add code
    to dissector_add and friends to validate the arguments:
       handle != null
       "pattern" (key) not already in the dissector table

    Is this OK ?  (If so, I'll add the code).

    (On a somewhat separate note: I see that multiple registrations
     happen for udp and tcp port 0.
     I'm still looking at these to understand and to see if OK.)