Ronald Oussoren added the comment:
It doesn't really live up to its description.
>From the start of the 'filtered' list:
* Messages about PyThread_acquire_lock appear to be false positives,
that name is a function that's called by the macros expanded on those
lines.
* Syntax error in _ctypes.h: the code is ugly, but is valid C; the
message is about:
else if PySlice_Check(item) {
This is valid because PySlice_Check is a macro that expands into
an expression with parentheses:
#define PySlice_Check(op) (Py_TYPE(op) == &PySlice_Type)
That said, I would have used explicit parentheses here.
* unused variable in _ctypes_test.c: false positives, the variable is
used in a function call two lines lower.
* callproc.c:1620: False positive because the tool doesn't know that
PyMem_Malloc is a malloc function and returns unitialized memory
(the first one that isn't a problem with the tool)
* messages about alloca: correct, I haven't looked seriously if the
use of alloca is defensible here.
* callproc.c:751: False positive, the variable is used by some
macros that are used in the function.
* the unused 'rtn' variable and 'break' in cursesmodule I've mentioned
in a previous message.
I haven't checked the rest of the list, but so far I'm not impressed by this
tool. That's too bad, static analysis tools can be helpful in improving code
quality.
The high rate of false positives might be due to the preprocessor feature
described in chapter 3 of the manual, the tool seems to be confused a lot by
code that uses macros. Getting it to run properly on the CPython tools might
therefore require significant tuning.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue18521>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
