BIND 10 #1025: logging argument should be more carefully checked

[BIND 10 Development]

#1025: logging argument should be more carefully checked
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:
  jinmei                             |                Status:  new
                       Type:         |             Milestone:
  defect                             |  Sprint-20110712
                   Priority:  major  |            Resolution:
                  Component:         |             Sensitive:  0
  Unclassified                       |           Sub-Project:  Core
                   Keywords:         |  Estimated Difficulty:  0.0
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:2 stephen]:
 > It will be difficult to catch the error in #1023 on a general basis -
 the problem lay in the evaluation of the argument to the logging call.  It
 just happened to manifest itself in a call to the logging code, but could
 have happened anywhere else.  Also, I don't see what sort of safer
 interface we could have - the argument was evaluated before the logging
 code was called, so the logging code could do nothing about it.
 >
 > However, I note that the arg() method of the logging Formatter class
 calls boost::lexical_cast to convert the argument to a string but does not
 handle a bad_lexical_cast exception.  I think it should catch the
 exception and use something like "INVALID_ARGUMENT" instead.

 Actually, what I meant (by "check") is to re-review all LOG_xxx's to
 see whether they have this type of (mostly) trivial dangerous usage.
 But if we complete #1024 that's perhaps sufficient.

 As for the additional check in boost::lexical_cast, we should at least
 catch boost exceptions within it and convert it.  I'm not so sure if
 obscuring it is a good idea in that IMO it's not a good idea if we
 simply e.g. return from a function when it sees a parameter that should
 not have a particular value in that context (e.g. a NULL pointer).

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