On Fri, Oct 12, 2007 at 05:11:17PM -0700, Dan Price wrote: > > I've been poking at the lint target for the C code and spotted a bunch > of problems with the target. Once I fixed that, I then found some bugs > in the code. Thanks, lint! > > However, I'm slightly stumped about how to handle the intersection of > python and C (since there seems to be no lint lib for the python > routines being called) and the intersection of python (which is large > files aware) and libelf (which is not). > > Does anyone have any thoughts about how best to cleanly handle this? > > For the large files issue, I get a bunch of errors like: > > "/usr/include/sys/stat_impl.h", line 55: warning: function argument > declared inconsistently: lstat(arg 2) in llib-lc:stat_impl.h(55) struct > stat * and stat_impl.h(55) struct stat * > > Since Python.h sets _FILE_OFFSET_BITS=64, whereas that's not the > compilation environment for the .o in question. > > If you want to see the issues here, I've attached a patch for the > first swing at correcting the makefile and some of the issues, and > it is simple to apply and try out-- just "make clean && make lint" > in the src/modules directory. >
I finally had to run lint against Python C API modules too. I was getting a lot of spurious errors, like you described; however, I made the following modifications, with some success. Added -n option. This surpresses the check of our header files against the default lint library. As a result, we don't get all of those warnings about structure mismatches. So as not to completely regress header-file checking, I added -Ncheck=%all,no%extern. This checks headerfiles, but not against the lintlib. The no%extern flag surpresses a warning that occurs if your .c file doesn't have a corresponding .h file. (Generally the case in our modules.) I also found a way to get rid of those annoying "warning: statement has no consequent: if" messages that occur with every call to Py_DECREF. Just for lint, if we #define the Python refcount debug support, all of these if statements get code stuck in them and the warnings go away. That's the purpose of the -DPy_REF_DEBUG. When I had gotten through that process, I did find that I had some legitimate lint warnings left to resolve. I've fixed those, but have some "arguments unused" warnings that still need to be addressed. What's the best way to handle this? The Python C API specifes what arguments these functions need to have, whether they're used or not. Should I be adding /*ARGSUSED*/ to the definitions? In some places, I could safely eliminate the unused argument and cast the function pointer to the type that Python expects; however, in other cases it's the first argument that's unused, so that approach obviously doesn't work. Thanks, -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
