BIND 10 #1112: RR type implementation: HINFO

BIND 10 Development do-not-reply at isc.org
Wed Sep 7 09:00:05 UTC 2011


#1112: RR type implementation: HINFO
-------------------------------------+-------------------------------------
                   Reporter:  shane  |                 Owner:  ocean
                       Type:         |                Status:  reviewing
  enhancement                        |             Milestone:
                   Priority:  minor  |  Sprint-20110927
                  Component:         |            Resolution:
  libdns++                           |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  3
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => ocean


Comment:

 Hello

 Replying to [comment:8 ocean]:
 > Replying to [comment:7 vorner]:
 > > Regarding the move of common methods to utils (or somewhere so they
 can be reused), I think it would not only be nice, but actually required.
 I think having two copies of the same code could qualify as a bug. So,
 will you move them, please?
 >
 > Done, move {{{getNextCharacterString()}}} to {{{character_string.cc/h
 files}}}

 As they are separate functions, should they have their own tests now?

 > > Another thing I noticed ‒ do the string data allow containing the
 quotes? How are they escaped in the text format, if they are allowed?
 (they don't seem to be at all in the code)
 >
 > Done. Add the double quotes escaping support.

 Hmm, as you referenced the 1035 RFC, I had a look there and it seems that
 character strings have quite complicated escaping support (so you can
 actually write {{{"\h\\\"ello"}}} and it would mean „{{{h\"ello}}}“).
 Strinctly speaking, the functions should be able to decode that. However,
 I'm thinking ‒ we surely must have a function to parse these somewhere.
 Or, if not, it should be added (but in that case, maybe as a separate
 ticket, I don't know…). What do other RRTypes parsing string data use?

 > > And, that might be more general problem, but both toWire methods have
 the exact same code. Should we consider reusing the code in some way?
 (template parameter and hidden implementation? Or something?)
 >
 > Done. Move them to a {{{toWireHelper()}}} function. But I'm not clear
 what '''hidden implementation''' means, can you give more detailed
 explanation? thanks.

 Well, it's not some kind of technical term, I just meant as little as
 possible should be visible of the function from outside. In fact, the body
 of the function might be put into the .cc file, as it is used only from
 there (template functions must have the body available when they are
 instantiated/called, but it is called only from the .cc). Unfortunately,
 the header can't be hidden there as well it seems.

 > BTW. I also update the code of {{{naptr_35.cc/h}}} which is implemented
 in #1130, can this be reviewed in this ticket or I need to reopen #1130?

 It's OK to be reviewed here.

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


More information about the bind10-tickets mailing list