[cfe-dev] [clang-tidy] Check for paranoic code (pointer checking)

Breno GuimarĂ£es via cfe-dev cfe-dev at lists.llvm.org
Wed Mar 15 21:54:43 PDT 2017


Hi all,

I started exploring clang-tidy to create checks for a large C++ code base
we have at work, with many developers with C background doing C++.

After doing the first tutorial on VirtualShadowingCheck, I wrote a check to
detect paranoic code using pointers. By paranoic, I mean this:

static void foo(T* p, ...) {
    if (!p) return;
    // do something
}

The method is doing the right thing to check the input, but the interface
itself could've been written with a reference, thus delegating to the
caller the responsability of doing the null check.

This is not at all always possible, since this style can be valid for
several reasons: pointers can refer diverse conceptual objects, e.g.
arrays), the function could be virtual, thus forced to follow the same
parameters, and so on.

But still, controversial as it is, I ran this check on LLVM code base.

llvm/tools/clang/lib/Sema/SemaLookup.cpp:3453 is one example. (the check
finds over 15 violations, but I haven't analyzed them all)

This function is one example that could be ignoring a potential mistake.
The caller could expect a valid pointer in at least some of those calls.
The convenience of writing:

foo(something->getPointer(), ...);

can stimulate the developer to not write checks/assertions for some cases
that he/she expects the pointer to be valid.

All that being said, I have some questions:

1 - Is the community receptive to such controversial checks? Or is
clang-tidy only interested in low false positive/ non controversial checks?
2 - Any feedback on this specific check?
3 - Are there more check ideas waiting for someone to implement so I could
pick up, learn more and actually contribute to the code base?


Thanks,
Breno Rodrigues GuimarĂ£es
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170316/dcfd8840/attachment.html>


More information about the cfe-dev mailing list