Extending Python with C or C++

Nick Craig-Wood nick at craig-wood.com
Wed Jan 7 13:31:15 CET 2009


Thomas Heller <theller at python.net> wrote:
>  Nick Craig-Wood schrieb:
> > Interesting - I didn't know about h2xml and xml2py before and I've
> > done lots of ctypes wrapping!  Something to help with the initial
> > drudge work of converting the structures would be very helpful.
> > 
> > ( http://pypi.python.org/pypi/ctypeslib/ )
> > 
> > I gave it a quick go and it worked fine.  I had to edit the XML in one
> > place to make it acceptable (removing a u from a hex number).
> 
>  If you are using a recent version of gccxml, then you should use the
>  ctypeslib-gccxml-0.9 branch of ctypeslib instead of the trunk. (I should
>  really merge the gccxml-0.9 branch into the trunk;-)
> 
>  If you are already using the branch and the XML file is not accepted,
>  then could you please provide a short C code snippet that reproduces
>  the problem so that I can fix it?

I'm using gccxml from debian testing 0.9.0+cvs20080525-1 which I guess
doesn't have the code from the branch in.

> > Here are my thoughts on the conversion :-
> > 
> > It converted an interface which looked like this (the inotify interface)
> > 
> >     struct inotify_event {
> >         int      wd;       /* Watch descriptor */
> >         uint32_t mask;     /* Mask of events */
> >         uint32_t cookie;   /* Unique cookie associating related
> >                               events (for rename(2)) */
> >         uint32_t len;      /* Size of name field */
> >         char     name[];   /* Optional null-terminated name */
> >     };
> > 
> > Into this
> > 
> >     class inotify_event(Structure):
> >         pass
> >     inotify_event._fields_ = [
> >         ('wd', c_int),
> >         ('mask', uint32_t),
> >         ('cookie', uint32_t),
> >         ('len', uint32_t),
> >         ('name', c_char * 0),
> >     ]
> > 
> > Which is a very good start.  However it defined these which clearly
> > aren't portable
> > 
> >     int32_t = c_int
> >     uint32_t = c_uint
> > 
> > Whereas it should have been using the ctypes inbuilt types
> > 
> >     c_int32
> >     c_uint32
> 
>  IMO this would be difficult to achive automatically.  There are cases
>  wher c_int is the correct type, in other cases c_int32 is correct.

Yes it is almost impossible difficult to achieve automatically -
exactly how far do you want to unravel the twisty turny mess of
typedefs that make up uint32_t?  It is easy to change the generated
output since it defines the type in one place.

uint32_t and friends (stdint.h) are standardised in C99 so might it be
reasonable to put some special cases in for them, expecially since the
corresponding types already exist in ctypes?

-- 
Nick Craig-Wood <nick at craig-wood.com> -- http://www.craig-wood.com/nick



More information about the Python-list mailing list