Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Python: Dev

2to3 for .c code (was Static analysis of CPython using coccinelle/spatch)

 

 

Python dev RSS feed   Index | Next | Previous | View Threaded


dmalcolm at redhat

Nov 18, 2009, 11:26 AM

Post #1 of 1 (421 views)
Permalink
2to3 for .c code (was Static analysis of CPython using coccinelle/spatch)

On Tue, 2009-11-17 at 19:45 -0500, Terry Reedy wrote:
> A.M. Kuchling wrote:
> > On Mon, Nov 16, 2009 at 03:27:53PM -0500, David Malcolm wrote:
> >> Has anyone else looked at using Coccinelle/spatch[1] on CPython source
> >> code?
> >
> > For an excellent explanation of Coccinelle, see
> > <http://lwn.net/Articles/315686/>.
>
> For those who have not looked, Coccinelle means ladybug (a bug-eating
> bug ;-) in French. Its principle use to to take C code and a SmPl file
> of high-level patch descriptions (fixers, in 2to3 talk) and produce a
> standard diff file. I wonder if this could be used to help people
> migrate C extensions to 3.1, by developing a SmPl file with the needed
> changes dictated by API changes. This is similar to its motivating
> application to Linux. From
>
> http://coccinelle.lip6.fr/
>
> "Coccinelle is a program matching and transformation engine which
> provides the language SmPL (Semantic Patch Language) for specifying
> desired matches and transformations in C code. Coccinelle was initially
> targeted towards performing collateral evolutions in Linux. Such
> evolutions comprise the changes that are needed in client code in
> response to evolutions in library APIs, and may include modifications
> such as renaming a function, adding a function argument whose value is
> somehow context-dependent, and reorganizing a data structure. "
>
> As I understand it, the problem with C extensions and 3.1 is the current
> lack of a "collateral evolution" tool like 2to3 for Python code.
Indeed; I think it may be possible to use Coccinelle for this.

Here's a .cocci semantic patch to convert non-PyObject* dereferences of
an "ob_type" field to use Py_TYPE macro instead.

@@
PyObject *py_obj_ptr;
type T;
T non_py_obj_ptr;
@@
(
py_obj_ptr->ob_type
|
- non_py_obj_ptr->ob_type
+ Py_TYPE(non_py_obj_ptr)
)


I was able to use this to generate the attached patch for the DBus
python bindings. Note that it leaves dereferences of a PyObject*
untouched, and works inside sub-expressions. (There's some noise at the
typedef of Server; I don't know why).

Hope this is helpful
Dave
Attachments: example-resultant-ob_type.patch (1.88 KB)

Python dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.