BIND 10 #2534: support minor cases for quoted character strings

[BIND 10 Development]

#2534: support minor cases for quoted character strings
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:  kean
                Type:  task          |                       Status:
            Priority:  medium        |  reviewing
           Component:  libdns++      |                    Milestone:
            Keywords:                |  bind10-1.2-release-freeze
           Sensitive:  0             |                   Resolution:
         Sub-Project:  DNS           |                 CVSS Scoring:
Estimated Difficulty:  4             |              Defect Severity:  N/A
         Total Hours:  0             |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by muks):

 * owner:  muks => kean


Comment:

 Hi Kean

 Apologies for the delayed response. Other tickets took away my time.

 Replying to [comment:13 kean]:
 > By those rules, using the latter "A" below instead of the longer
 > string "Test-String" for easier typing, the input string (as a
 > sequence of bytes):
 >
 > {{{
 >    A    "    A    "
 >    0x41 0x22 0x41 0x22
 > }}}
 >
 > Since the string does not start with a quote, it is not a QSTRING,
 > just a normal string. That is, it is the string 'A"A"', where ' is
 > used here solely as a delimiter. When producing the text version of
 > that string, I would expect the returned result to be:
 >
 > {{{
 >    "    A    \    "    A    \    "
 >    0x22 0x41 0x5c 0x22 0x41 0x5c 0x22
 > }}}

 Even going by your description, it seems the representation above seems
 incorrect; it is probably lacking a trailing double-quote (") to match
 the beginning double-quote.

 The above is not the requested behavior. The following is the unittest
 code in the branch as put to review, which is the cause of concern:

 {{{
     // Check escape behavior
     const TypeParam double_quotes("Test-String\"Test-String\"");
     EXPECT_EQ("\"Test-String\" \"Test-String\"", double_quotes.toText());
 }}}

 Here, the un-escaped string (value of `double_quotes`) is:
 {{{
 Test-String"Test-String"
 }}}

 The lexer sees it as:

  1. `Test-String` (a STRING token, followed by...)
  1. `"Test-String"` (a QSTRING token)

 Both parsed tokens' string values are `Test-String` respectively.

 This is because `"` is now a delimiter (to match BIND 9; see the ticket
 description).

 To you, I suggested a reading of `<character-string>` and the TXT RDATA
 so you are aware that multiple `<character-string>`s can occur in a
 single TXT RDATA. This is what is happening here. As RDATA, it looks
 like:

 {{{
 0x0b 'T' 'e' 's' 't' '-' 'S' 't' 'r' 'i' 'n' 'g'
 0x0b 'T' 'e' 's' 't' '-' 'S' 't' 'r' 'i' 'n' 'g'
 }}}

 in a single RR.

 When rendering back to string, each `<character-string>` is rendered as
 a quoted string separated by whitespace:

 {{{
 "Test-String"
 "Test-String"
 }}}

 In C++ syntax, it is the value of this string literal:
 {{{
 "\"Test-String\" \"Test-String\""
 }}}

 >
 > Or, when adding in the quotes for a C++ string, I would expect the
 result to be:
 >
 > {{{
 >    "\"A\\\"A\\\""
 > }}}
 >
 > Which is exactly how the test was before your change. Therefore, since
 > you didn't answer it the first time around I must ask again, did you
 > change the test case to make it pass or did you cognitively compute
 > the desired outcome to have that space there?

 You are asking if I adjusted the test providing the matching value just
 to "accommodate a failing test". It's very insulting. Do you really
 want me to answer that? I don't wilfully put broken code to review.

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