Issue 30287: cpython and Clang Static Analyzer (original) (raw)

Issue30287

Created on 2017-05-05 22:13 by dilyan.palauzov, last changed 2022-04-11 14:58 by admin.

Messages (4)
msg293145 - (view)	Author: Дилян Палаузов (dilyan.palauzov)	Date: 2017-05-05 22:13
I compiled cpython using Clang 4.0 Static Analyzer with scan-build ./configure --enable-loadable-sqlite-extensions --enable-ipv6 --with-system-expat --with-system-ffi --with-system-libmpdec scan-build make and here are the results https://mail.aegee.org/dpa/scan-build-python-a1054c3b00/ Please note, that the information is only about what gets actually compiled, code disabled by #if .. #endif is not considered (e.g. when determining whether a variable assignment is useless). There are probably some false-positives. Consider this as information, I do not pretend there are any bugs found by the static analyzer.
msg293179 - (view)	Author: Mark Dickinson (mark.dickinson) *	Date: 2017-05-07 06:59
Thanks for this. I took a look at the 5 reports for Objects/longobject.c, and I don't think there's any action to be taken on any of them. (Two false positives; two "dead assignments" that are used when asserts are enabled, and one division-by-zero that depends on a function being called in a way that never happens in practice.) * Objects/longobject.c:2823 Assigned value is garbage or undefined This is a false positive. Here we have: a_bits <= a_size * PyLongShift shift_digits = (a_bits - DBL_MANT_DIG - 2) / PyLong_SHIFT; and then we call v_rshift(x_digits, ..., a_size - shift_digits, ...), which fills the first a_size - shift_digits entries of x_digits. Since DBL_MANT_DIG >= PyLong_SHIFT, we have shift_digits < a_size, so x_digits[0] is always initialised by v_rshift. * Objects/longobject.c:2723 Dead assignment The value of the assignment is used in a following assert statement; I don't think this should be changed. * Objects/longobject.c:2463 Dead assignment Again, the value of the assignment is used in an assert. * Objects/longobject.c:1828 Division by zero This function will never get called with bits=0. There are asserts to check this. * Objects/longobject.c:2830 Assigned value is garbage or undefined This is another false positive, similar to the first one. Analysing the arithmetic shows that x_digits[0] is always defined.
msg293184 - (view)	Author: Дилян Палаузов (dilyan.palauzov)	Date: 2017-05-07 09:20
I forgot to pass --with-pydebug to ./configure in order to consider also the asserts. Here we go: scan-build ./configure --enable-loadable-sqlite-extensions --enable-ipv6 --with-system-expat --with-system-libmpdec --with-pydebug scan-build -o /home/didopalauzov/public_html/scan-build-python-3763ea865c make The output, which has now 9 hints less, is at https://mail.aegee.org/dpa/scan-build-python-3763ea865c/ The assignments in Modules/socketmodule.c:1456 and Modules/_datetimemodule.c:2232 are correctly detected as superfluous. In Objects/longobject.c/long_format_binary: default: assert(0); /* shouldn't ever get here*/ bits = 0; /* to silence gcc warning */ I guess return -1 instead of bits=0 will silent both gcc and the static analyzer warning.
msg293475 - (view)	Author: Mark Dickinson (mark.dickinson) *	Date: 2017-05-11 08:07
> I guess return -1 instead of bits=0 will silent both gcc and the static analyzer warning. That's a possibility, though we should also set an exception in that case (since returning an error value without setting an exception is also something that might be picked up by a CPython-oriented static analyser in the future).