[issue18521] [cppcheck] Full report

[Ronald Oussoren]

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 <report at bugs.python.org>
<http://bugs.python.org/issue18521>
_______________________________________