svn+ssh://pythondev@svn.python.org/python/trunk/Lib/ctypes
........
r54248 | thomas.heller | 2007-03-09 21:39:22 +0100 (Fr, 09 Mär 2007) | 7 lines
Bug #1651235: When a tuple was passed to a ctypes function call,
Python would crash instead of raising an error.
The crash was caused by a section of code that should have been
removed long ago, at that time ctypes had other ways to pass
parameters to function calls.
........
svn+ssh://pythondev@svn.python.org/python/trunk/Modules/_ctypes
........
r53556 | thomas.heller | 2007-01-25 19:34:14 +0100 (Do, 25 Jan 2007) | 3 lines
Fix for #1643874: When calling SysAllocString, create a PyCObject
which will eventually call SysFreeString to free the BSTR resource.
........
be true if we didn't malloc the code? Seems like the code is wrong
or could use comments.
Also verify if the buildbots are working properly for the 2.5 branch.
Check this and raise an error when something else is used - before
this change ctypes would hang or crash when such a callback was
called. This is a partial fix for #1574584.
Backported from trunk.
The cast function did not accept c_char_p or c_wchar_p instances
as first argument, and failed with a 'bad argument to internal function'
error message.
Anonymous structure fields that have a bit-width specified did not work,
and they gave a strange error message from PyArg_ParseTuple:
function takes exactly 2 arguments (3 given).
Add asserts to check for 'impossible' NULL values, with comments.
In one place where I'm not 1000% sure about the non-NULL, raise
a RuntimeError for safety.
This should fix the klocwork issues that Neal sent me. If so,
it should be applied to the release25-maint branch also.
of the Python part of a callback function to C. If it cannot be
converted, call PyErr_WriteUnraisable with the exception we got.
Before, arbitrary data has been passed to the calling C code in this
case.
(I'm not really sure the NEWS entry is understandable, but I cannot
find better words)
PyObject_stgdict() and PyType_stgdict() calls are non-NULL before
dereferencing the result. Hopefully this fixes what klocwork is
complaining about.
Fix a few other nits as well.
ctypes instances no longer have the internal and undocumented
'_as_parameter_' attribute which was used to adapt them to foreign
function calls; this mechanism is replaced by a function pointer in
the type's stgdict.
In the 'from_param' class methods, try the _as_parameter_ attribute if
other conversions are not possible.
This makes the documented _as_parameter_ mechanism work as intended.
Change the ctypes version number to 1.0.1.
storage before converting the result to C data. See the comment in
the code for details.
Provide a better context for errors when the conversion of a callback
function's result cannot be converted.
Also fix a few memory leaks in other failure scenarios.
It seems that if b_objects == Py_None, we will have an extra ref to
b_objects. Add XXX comment so hopefully someone documents why the
else isn't necessary or adds it in.
Reported by Klocwork #20
Add a new function uses_seh() to the _ctypes extension module. This
will return True if Windows Structured Exception handling (SEH) is
used when calling functions, False otherwise.
of bugs in that port. The most annoying ones were due to some subtle differences
between the document ABI and the actual implementation :-(
(there are no python unittests that fail without this patch, but without it
some of libffi's unittests fail).
will return True if Windows Structured Exception handling (SEH) is
used when calling functions, False otherwise.
Currently, only MSVC supports SEH.
Fix the test so that it doesn't crash when run with MingW compiled
_ctypes. Note that two tests are still failing when mingw is used, I
suspect structure layout differences and function calling conventions
between MSVC and MingW.
It seems that the definition of '__attribute__(x)' was responsible for
the compiler ignoring the '__fastcall' attribute on the
ffi_closure_SYSV function in libffi_msvc/ffi.c, took me quite some
time to figure this out.