BIND 10 #1784: b10-resolver incorrectly uses SyncUDPServer

[BIND 10 Development]

#1784: b10-resolver incorrectly uses SyncUDPServer
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:         |             Milestone:
  defect                             |  Sprint-20120320
                   Priority:  very   |            Resolution:
  high                               |             Sensitive:  0
                  Component:         |           Sub-Project:  DNS
  resolver                           |  Estimated Difficulty:  0
                   Keywords:         |           Total Hours:  0
            Defect Severity:  N/A    |
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by jelte):

 * owner:  jelte => jinmei


Comment:

 Replying to [comment:6 jinmei]:
 >
 >
 > Thanks for the checks and corrections.  These seem good.  I've added
 > comments about the null check after getaddrinfo() because, technically
 > (per the API contract) the check should be redundant.
 >

 Yeah, my documentation wasn't explicitly clear about that. BTW, i *think*
 that if we don't reuse the error int and put the use of res-> directly in
 the if error check then cppcheck will swallow it. But that would mean
 repeating the error handling twice, not worth it imo :)

 > > So the addServer calls are the thing you were wondering we should
 >   keep? I'd say remove them. (they even use the old dlog() calls, but
 >   have other problems as well)
 >
 > Yeah I think we should remove them, even if we have vague expectation
 > that we may want to reuse them in future (YAGNI applies here).  I
 > think it should go to a separate ticket (and guess it would be a
 > perfect item for "hardening").
 >

 ack, that code is a good example of deterioration by lack of use :)

 > > Should we warn/error on unknown options in addServerUDPFromFD?
 (currently they are ignored)
 >
 > Hmm, probably.  Although it's quite unlikely to be misused (because it's
 > enum and you need to use a cast to decieve the compiler), it could still
 > be possible that an application built with a new version of header
 > (and using a new option flag) uses an old version of library binary.
 >
 > So I've added the check.

 ok cool

 all good, please merge :)

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