[Python-Dev] testing the C API in the test suite (was: bug in PyLong_FromLongLong (PR#324))

Trent Mick trentm@activestate.com
Thu, 11 May 2000 15:14:45 -0700

> Date:    Wed, 10 May 2000 15:37:30 -0400
> From:    Thomas.Malik@t-online.de
> To:      python-bugs-list@python.org
> cc:      bugs-py@python.org
> Subject: [Python-bugs-list] bug in PyLong_FromLongLong (PR#324)
> Full_Name: Thomas Malik
> Version: 1.5.2
> OS: all
> Submission from: p3e9ed447.dip.t-dialin.net (
> there's a bug in PyLong_FromLongLong, resulting in truncation of negative 64 bi
> t
> integers. PyLong_FromLongLong starts with: 
> 	if( ival <= (LONG_LONG)LONG_MAX ) {
> 		return PyLong_FromLong( (long)ival );
> 	}
> 	else if( ival <= (unsigned LONG_LONG)ULONG_MAX ) {
> 		return PyLong_FromUnsignedLong( (unsigned long)ival );
> 	}
> 	else {
>              ....
> Now, if ival is smaller than -LONG_MAX, it falls outside the long integer range
> (being a 64 bit negative integer), but gets handled by the first if-then-case i
> n
> above code ('cause it is, of course, smaller than LONG_MAX). This results in
> truncation of the 64 bit negative integer to a more or less arbitrary 32 bit
> number. The way to fix it is to compare the absolute value of imax against
> LONG_MAX in the first condition. The second condition (ULONG_MAX) must, at
> least, check wether ival is positive. 

To test this error I found the easiest way was to make a C extension module
to Python that called the C API functions under test directly. I can't
quickly think of a way I could have shown this error *clearly* at the Python
level without a specialized extension module. This has been true for other
things that I have been testing.

Would it make sense to create a standard extension module (called '__test' or
something like that) in which direct tests on the C API could be made? This
would be hooked into the standard testsuite via a test_capi.py that would:
- import __test
- run every exported function in __test (or everyone starting with 'test_',
  or whatever)
- the ImportError could continue to be used to signify skipping, etc
  (although, I think that a new, more explicit TestSuiteError class would be
  more appropriate and clear)

Does something like this already exist that I am missing?

This would make testing some things a lot easier, and clearer. Where
some interface is exposed to the Python programmer it is appropriate to test
it at the Python level. Python also provides a C API and it would be
appropriate to test that at the C level.

I would like to hear some people's thoughts before I go off and put anything


Trent Mick