[cfe-dev] [GSoC] Interested in idea: "Find null smart pointer dereferences with the Static Analyzer"

Artem Dergachev via cfe-dev cfe-dev at lists.llvm.org
Sun Mar 8 18:30:47 PDT 2020


Hey!

Welcome. Let's see.

Nullability checker isn't the one that you're looking for. It's a 
different beast that governs hunt for null dereferences via so-called 
"nullability annotations". Like, a language extension is provided 
through which the programmer can tell the analyzer which variables / 
functions may or may not hold / produce null pointers, and the analyzer 
checks whether it makes sense how these nullable and non-null values 
propagate from one function to another. So it's the same problem but a 
different technique. It is targeted mostly at finding crashes in 
Objective-C apps that pass a lot of pointers around across many 
user-defined functions.

The proposed GSoC project is of a different nature: we want to teach the 
static analyzer about a very specific C++ API, but we want to teach it 
much more thoroughly. It's not enough to know that 
std::unique_ptr::operator->() may occasionally return a null pointer; 
we'd much rather know when exactly does it return a null pointer (eg., 
if the smart pointer is freshly default-constructed).

If you want to study existing checkers, check out:
- MoveChecker - the use-after-move checker which already finds *some* 
null smart pointer dereferences, given that they're guaranteed to be 
null after move.
- SmartPtrChecker currently does almost nothing, but that's probably 
where you put your code into :)
- IteratorChecker is a large ongoing pioneer project to find iterator 
and container related bugs such as dereferencing vector.end(). It's the 
closest thing to what you'll be implementing, but its handling of C++ 
objects is outdated and overly complicated because some new facilities 
for C++ support (mostly the ones explained in the second half of 
https://www.youtube.com/watch?v=4n3l-ZcDJNY)  weren't in place yet when 
it all started.

Once you understand the project a bit better and like it, the next step 
is to discuss here (in this mailing list) what is the best way to 
implement the checker. The ultimate outcome of this discussion will be a 
so-called "GSoC proposal". It's a few pages of text that you write, post 
here for more discussion, and eventually upload to the GSoC website. 
According to the GSoC timeline, the proposal should be submitted by the 
end of March. The proposal summarizes how *you* understand the project 
and how *you* plan to tackle it during the summer.

Good luck on your GSoC path!
Artem.


On 3/7/20 3:40 PM, Nithin Vadukkumchery Rajendrakumar via cfe-dev wrote:
>
> Greetings,
>
>
> I am interested to participate in GSoC 2020. I am particularly 
> interested in the project idea "Find null smart pointer dereferences 
> with the Static Analyzer". I am doing my masters in computer science 
> and interested in program analysis and verification. I thought 
> GSoC2020 will be a wonderful opportunity to learn more about Clang 
> Static Analyzer and contribute.
>
>
> I have started reading about smart pointers in C++ to get a good grasp 
> of the concepts. Also, has some experience in implementing Clang 
> Static Analyzer simple checks(similar to SimpleStreamChecker) from the 
> tutorials. I read through few available tutorials and have some basic 
> idea about Control Flow Graph, Exploded Graph and Symbolic Values. I 
> have read the paper "A memory model for static analysis of C programs" 
> to get some theoretical background. I also started looking into 
> NullabilityChecker.cpp 
> <https://github.com/llvm/llvm-project/blob/master/clang/lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp> to 
> understand the codebase.
>
> I would like to know is this the right place to look?
>
> Could anyone please help me on what should I do next?
>
> ----
> Thanks & Regards,
> Nithin
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev



More information about the cfe-dev mailing list