Consider the library 'c_lib.so' consisting of a single function 'c_func'

int c_func ( double *arg0, double *arg1, double *arg2, double *arg3,
             double *arg4, double *arg5, double *arg6) {
    printf("Value of arg0 is %p\n", arg0);
    printf("Value of arg1 is %p\n", arg1);
    printf("Value of arg2 is %p\n", arg2);
    printf("Value of arg3 is %p\n", arg3);
    printf("Value of arg4 is %p\n", arg4);
    printf("Value of arg5 is %p\n", arg5);
    printf("Value of arg6 is %p\n", arg6);
    return 0;
}

and the following snippet:

from ctypes import *
c_lib = CDLL('c_lib.so')
t = POINTER(c_double)
c_lib.c_func.argtypes = [t,t,t,t,t,t,t]

def call_c_func():
    nptr = None
    c_lib.c_func(nptr, nptr, nptr, nptr, nptr, nptr, nptr)

The output I get from call_c_func() with Python 2.6 and Python 2.5 on a
64 bit Linux box is (it probably won't happen on 32 bit systems):

Value of arg0 is (nil)
Value of arg1 is (nil)
Value of arg2 is (nil)
Value of arg3 is (nil)
Value of arg4 is (nil)
Value of arg5 is (nil)
Value of arg6 is 0xa00000000

The reason appears to be that in 'PointerType_from_param' (_ctypes.c)
Py_None is converted to a Python integer of value 0.  Later, in
'ConvParam' (callproc.c), this integer ends up as a 4 byte integer type
on the argument stack for ffi. I don't know anything about ffi, but this
looks at least suspicious on any platform where sizeof(void*) is 8.

I propose to remove NULL pointer handling from the above from_param
function, since Py_None is properly handled by ConvParam itself. A patch
against the 2.6 maintenance branch is attached.