On Wed, May 09, 2012 at 11:39:02AM +0200, Jakub Hrozek wrote:
On Thu, Apr 26, 2012 at 01:51:39PM +0200, Jakub Hrozek wrote:
> Developers can also run the clang tool themselves - I'll add info how
> into our Developers page.
https://fedorahosted.org/sssd/wiki/DevelTips#Usingclangtoperformstaticana...
On today's git HEAD, clang reports the following 20 bugs:
*
http://jhrozek.fedorapeople.org/sssd-clang-llvm/
Some of them are false positives, I'll address the rest:
* API Argument with 'nonnull' attribute passed null - util/sss_krb5.c:1108
** real bug
* API Argument with 'nonnull' attribute passed null -
sss_client/nss_mc_common.c:201
** I'd like someone more familiar with the fast cache code to take a
look. Is it possible for the assignment at sss_client/nss_mc_common.c:182
to yield rec_len == 0 ?
* API Argument with 'nonnull' attribute passed null -
responder/nss/nsssrv_mmap_cache.c:714
** False positive, mc_ctx->fd would be still -1 so the code wouldn't
run
* Logic error Assigned value is garbage or undefined -
providers/krb5/krb5_child_handler.c:164
** False positive, the path clang describes can never be run, stops
3 and 9 cannot happen at the same time
* Most of the "dead storage" warnings are false positives due to our
use of in_transaction. I'll fix the rest, although it's not terribly
urgent to do so.
* Logic error Dereference of null pointer - sss_client/common.c:142
** False positive, poll would have to fail and return -1 but set
errno to 0 at the same time.
* Logic error Dereference of null pointer - ldb_modules/memberof.c:328
** Seems like a false positive to me, but I asked Jan to double check
* Logic error Dereference of null pointer - confdb/confdb.c:1030
** I'm not sure if this code is still useful, it seems like it was
written to support changing configuration on the fly?
* Logic error Dereference of null pointer providers/ldap/sdap_async.c:1125
** False positive, state->nserverctrls would be 0 after step 5 and
the loop in step 7 would never enter
* Logic error Dereference of null pointer - resolv/async_resolv.c:2143
** This seems like a real bug but the code path can't be reached with
how the caller uses reply_weight_rearrange(). We should make it more
robust, though.
Because clang is also able to output machine-readable XML results, I
plan to make a "whitelist" of known false positives and run the analysis
in cron nightly to catch new bugs automatically.