Thomas Heller <thel...@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 <n...@craig-wood.com> -- http://www.craig-wood.com/nick -- http://mail.python.org/mailman/listinfo/python-list