BIND 10 #363: "H" and "I" are probably harmful for PyArg_ParseTuple()

BIND 10 Development do-not-reply at isc.org
Tue Mar 15 12:10:33 UTC 2011


#363: "H" and "I" are probably harmful for PyArg_ParseTuple()
-------------------------------------+-------------------------------------
                 Reporter:  jinmei   |                Owner:  jinmei
                     Type:  defect   |               Status:  reviewing
                 Priority:  minor    |            Milestone:  A-Team-
                Component:           |  Sprint-20110316
  DNSPacket API                      |           Resolution:
                 Keywords:           |            Sensitive:  0
Estimated Number of Hours:  0.0      |  Add Hours to Ticket:  0
                Billable?:  1        |          Total Hours:  0
                Internal?:  0        |
-------------------------------------+-------------------------------------
Changes (by zzchen_pku):

 * owner:  zzchen_pku => jinmei


Comment:

 Replying to [comment:7 jinmei]:
 > It didn't pass a test for me:
 > {{{
 > Running test: message_python_test.py
 > ..........E...........
 > ======================================================================
 > ERROR: test_header_flag (__main__.MessageTest)
 > ----------------------------------------------------------------------
 > Traceback (most recent call last):
 >   File
 "/Users/jinmei/src/isc/git/bind10-363/src/lib/dns/python/tests/message_python_test.py",
 line 114, in test_header_flag
 >     self.assertRaises(TypeError, self.r.set_header_flag, 0x80000000)
 >   File
 "/opt/local/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/unittest.py",
 line 589, in assertRaises
 >     callableObj(*args, **kwargs)
 > OverflowError: Message header flag out of range
 > }}}
 For my 32bit OS,the range of interger is (-0x80000000, 0x7fffffff),so the
 test will throw TypeError for 0x80000000. Since the unittest is platform
 dependent,I don't think it make sense to keep it.
 > Also, it was not clear to me why you chose long (instead of int) in
 > some cases while choosing int for others.  Please clarify the
 > rationale.
 I find this in python2 doc:
 {{{
 python2 supports numeric types: plain integers, long integers
 Plain integers (also just called integers) are implemented using long in
 C, which gives
 them at least 32 bits of precision,Long integers have unlimited precision.
 }}}
 and also
 {{{
 In Python 3, there is only one integer type, called int, which mostly
 behaves like the
 long type in Python 2.
 }}}
 PyArg_ParseTuple() is responsible for converting a Python integer to a
 plain C numeric type, as described above, I think long precision is more
 suitable to prevent overflow.

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


More information about the bind10-tickets mailing list