[issue18521] [cppcheck] Full report
Serhiy Storchaka added the comment: Shouldn't converttuple() in getargs.c set levels[1] = 0; after second levels[0] = i+1;? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18521 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18521] [cppcheck] Full report
Serhiy Storchaka added the comment: Agree that all other looks false positive or unimportant. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18521 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18521] [cppcheck] Full report
Georg Brandl added the comment: Shouldn't converttuple() in getargs.c set levels[1] = 0; after second levels[0] = i+1;? I think it is fine, since convertitem() or converttuple() called from convertitem() will set their levels[0] (which is levels[1] in the original context) to zero on error. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18521 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18521] [cppcheck] Full report
Georg Brandl added the comment: Closing this one as Fixed, then. Thanks everybody. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18521 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18521] [cppcheck] Full report
Ezio Melotti added the comment: I grouped the errors by message and checked of there were any actual errors. Most of the reports seemed wrong or false positive, but a few looked fixable. I haven't checked the Unusued variable ones, because they are harmless (even thought we could clean them up), and the value assigned to a var that is never used (I suspect most of these are to silence compiler warnings about unused return values). These two categories cover more than half of the errors. I attach the file with the grouped content and some notes I took about the errors I looked at in case someone wants to check the remaining issues. -- nosy: +ezio.melotti, haypo, serhiy.storchaka versions: +Python 3.4 -Python 3.5 Added file: http://bugs.python.org/file32108/cppcheck_reports_filtered_grouped.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18521 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18521] [cppcheck] Full report
Roundup Robot added the comment: New changeset eaeaed43ff1c by Georg Brandl in branch 'default': Re #18521: fix not-quite-C syntax that works only because the PyXXX_Check are macros defined with () around them. http://hg.python.org/cpython/rev/eaeaed43ff1c -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18521 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18521] [cppcheck] Full report
Roundup Robot added the comment: New changeset 7396d10405db by Georg Brandl in branch 'default': Re #18521: remove assignments of variables that are immediately reassigned. http://hg.python.org/cpython/rev/7396d10405db -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18521 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18521] [cppcheck] Full report
Roundup Robot added the comment: New changeset 63bc2fe28a6e by Georg Brandl in branch 'default': Re #18521: move array bounds check before array access. http://hg.python.org/cpython/rev/63bc2fe28a6e -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18521 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18521] [cppcheck] Full report
Georg Brandl added the comment: I fixed some items from Ezio's list that I think were legitimate; the rest is mostly invalid. -- nosy: +georg.brandl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18521 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18521] [cppcheck] Full report
Julien Nabet added the comment: Thank you for your feedback, you can close this tracker. -- ___ 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
[issue18521] [cppcheck] Full report
Martin v. Löwis added the comment: Julien: I propose to resolve this issue in the same way as we have done previously with analysis tools (with some unfortunate exceptions). Somebody motivated enough (hopefully you) agrees to initially study the tool output, and ideally also then agrees to run the tool on a regular basis (but this is really not mandatory - the help with the initial run is already appreciated). You would then filter out the reports, and see which of them are useful. If you can, have the tool silence the bogus reports (e.g. with a configuration file). For the issues that you consider valid, please file individual bug reports (possibly combining related reports, e.g. by module or by error kind, but only if they can all be reasonably fixed in a single commit). The key concern of the developers here is probably this: a) there is no doubt that getting issues detected and fixed would be a helpful contribution, but b) the amount of false positives makes it unattractive to actually run the tool yourself. If you do not want to volunteer, this is fine as well. Just don't feel sad if the issue gets closed with no action. -- nosy: +loewis ___ 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
[issue18521] [cppcheck] Full report
Ronald Oussoren added the comment: What is cppcheck? The report contains some very dodgy false positives, like: [Modules/_cursesmodule.c:1095]: (style) Variable 'rtn' is assigned a value that is never used. [Modules/_cursesmodule.c:1097]: (style) Unused variable: break 1) The rtn is used further on the function 2) break is not a variable at all, but a C keyword There are also valid messages, but there appear to be a lot of false positives (based on the limited amount of checking that I've done) -- nosy: +ronaldoussoren ___ 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
[issue18521] [cppcheck] Full report
Julien Nabet added the comment: quotation from http://en.wikipedia.org/wiki/Cppcheck : Cppcheck is a static code analysis tool for the C and C++ programming languages or from http://cppcheck.sourceforge.net/ Cppcheck is a static analysis tool for C/C++ code. Unlike C/C++ compilers and many other analysis tools it does not detect syntax errors in the code. Cppcheck primarily detects the types of bugs that the compilers normally do not detect. The goal is to detect only real errors in the code (i.e. have zero false positives). -- ___ 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
[issue18521] [cppcheck] Full report
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
[issue18521] [cppcheck] Full report
New submission from Julien Nabet:
Hello,
I retrieved Cpython sources today and runned cppcheck (git updated today) on
the whole sources with enable=all
I attached the full report.
There are certainly false positive but some reports may help, eg:
[Python/getargs.c:379]: (style) Array index 'i' is used before limits check.
Indeed, here is the code:
379 while (levels[i] 0 i 32 (int)(p-buf) 220) {
[Modules/md5module.c:345] - [Modules/md5module.c:342]: (style) Found duplicate
branches for 'if' and 'else'
342 if (Py_TYPE(self) == MD5type) {
343 if ( (newobj = newMD5object())==NULL)
344 return NULL;
345 } else {
346 if ( (newobj = newMD5object())==NULL)
347 return NULL;
348 }
[Objects/iterobject.c:87]: (error) Uninitialized variable: seqsize
[Objects/setobject.c:549]: (error) Address of local auto-variable assigned to a
function parameter
etc.
Hope it helps.
Julien
--
files: cppcheck_reports.txt
messages: 193442
nosy: serval2412
priority: normal
severity: normal
status: open
title: [cppcheck] Full report
versions: Python 3.5
Added file: http://bugs.python.org/file30995/cppcheck_reports.txt
___
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
[issue18521] [cppcheck] Full report
Christian Heimes added the comment: The report contains too much noise to be useful. I suggest that you remove some of the noise. * get rid of The scope of the variable 'foo' can be reduced.. It's nit-picking. * ignore 3rd party code: Modules/_ctypes/libffi*, Modules/_sha3/keccak, Modules/expat, Modules/_decimal/libmpdec * ignore Windows stuff on non-Windows platforms: PC, PCbuild, Tools/msi -- nosy: +christian.heimes ___ 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
[issue18521] [cppcheck] Full report
Julien Nabet added the comment: Here's a new version of the file after some filtering (for the record, I used this command line: grep -v 'The scope' cppcheck_reports.txt |grep -v 'Modules/_ctypes/libffi' |grep -v Modules/_sha3/keccak| grep -v Modules/expat | grep -v Modules/_decimal/libmpdec |grep -v PC | grep -v msi | grep -v 'Skipping config' |grep -v 'Too many') Is it ok for you? Julien -- Added file: http://bugs.python.org/file30996/cppcheck_reports_filtered.txt ___ 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
