BIND 10 #2571: type error in data.cc

BIND 10 Development do-not-reply at isc.org
Fri Dec 21 09:31:48 UTC 2012


#2571: type error in data.cc
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:  shane
                Type:  defect        |                       Status:
            Priority:  medium        |  accepted
           Component:  build system  |                    Milestone:  New
            Keywords:                |  Tasks
           Sensitive:  0             |                   Resolution:
         Sub-Project:  Core          |                 CVSS Scoring:
Estimated Difficulty:  0             |              Defect Severity:  N/A
         Total Hours:  0             |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by shane):

 Okay, since this broke the build on my Raspberry Pi, I made the fixes to
 get this to work.

 The main issue here is that data.cc was treating character-by-character
 input having type char, when in fact it has type int. There is a FAQ
 covering the use of EOF which goes into great detail:

 http://faq.cprogramming.com/cgi-
 bin/smartfaq.cgi?id=1043284351&answer=1048865140

 I've adjusted the appropriate types in data.cc, as well as changing a few
 conversions in exceptions.

 There was also an instance in perfdhcp that I changed for similar-though-
 not-identical reasons.

 It turns out that because of the type conversion issue, the JSON-from-
 string was actually broken before, in the case where the character '\xFF'
 appeared in the string. I've added a test for that case, which breaks
 under the old code but works after the fixes.

 This brings up a slightly larger issue, which is that in principle JSON
 strings are Unicode, defaulting to UTF-8:

 http://tools.ietf.org/html/rfc4627#section-3

 This may not apply to our situation, as it would mean that we need to use
 ICU or something like that and convert to Unicode throughout:

 http://site.icu-project.org/

 I think just being 8-bit clean is good enough at this point, but if you
 think otherwise please feel free to open a ticket.

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


More information about the bind10-tickets mailing list