Extending Python with C or C++
Nick Craig-Wood
nick at craig-wood.com
Wed Jan 7 07:31:15 EST 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