BIND 10 #1754: small issues in LabelSequence

BIND 10 Development do-not-reply at isc.org
Sun Mar 4 08:44:26 UTC 2012


#1754: small issues in LabelSequence
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  defect        |  UnAssigned
            Priority:  major         |                       Status:  new
           Component:  libdns++      |                    Milestone:  Next-
           Sensitive:  0             |  Sprint-Proposed
         Sub-Project:  DNS           |                     Keywords:
Estimated Difficulty:  0             |              Defect Severity:  N/A
         Total Hours:  0             |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
 - case consideration of equals() seems to be reversed.
 {{{#!c++
     /// Performs a (optionally case-insensitive) comparison between this
     /// LabelSequence and another LabelSequence.
 ...
     bool equals(const LabelSequence& other, bool case_sensitive = false)
 const;
 }}}
   Unless 'case_sensitive = true' means case insensitive (if so it's
   confusing, and would not be a good default anyway, because name
   comparison is case insensitive in most cases).

 - The actual implementation of equal() shold also be adjusted:
 {{{#!c++
     if (case_sensitive) {
         return (strncasecmp(data, other_data, len) == 0);
     } else {
         return (strncmp(data, other_data, len) == 0);
     }
 }}}

 - Also, strncasecmp() is not in the C++ standard library and it's less
   portable.  And, while it happens to be okay today, I'm afraid it's a
   bit fragile to assume the label length field can be compared as a
   case insensitive value.

 - Maybe pedantic, but I'm afraid using char* is not technically
   correct because size of char may not necessarily be 8-bit (and with
   this class we'd use the pair of char* + its "size" as a 8-bit
   wire-format sequence.

 (As a hindsight using std::string (which is basic_string<char>) as the
 internal representation of Name was also a bad choice, and I've been
 wanting to fix it but missing the chance.  Maybe we should clarify
 that, e.g., by changing to basic_string<uint8_t> at this opportunity).

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


More information about the bind10-tickets mailing list