[cfe-dev] [analyzer][RFC] The future of StdLibraryFunctionsChecker and other checkers responsibility

[Gábor Márton via cfe-dev]

Hi,

During the review of https://reviews.llvm.org/D82288 Kristof and I have
started an independent discussion about the responsibilities
of StdLibraryFunctionsChecker. This may involve other checkers too. We'd
like to develop a community accepted strategy, so agreed to move this
discussion forward to the mailing list.

One of my goals with StdLibraryFunctionsChecker is to add argument
constraints to functions in the C, C++ and POSIX standard. It is very easy
to gather these argument constraints and apply them massively. By doing
this, the analysis can be more precise, so, I see a lot of gain here.
However, some of these argument constraints could be handled in more
specific checkers too, e.g. in CStringModeling, MallocChecker or in
StreamChecker.

Let's take for instance `popen`. In the mentioned patch I am adding a
simple summary with argument constraints. However, sooner or later popen
could be modeled in StreamChecker once that is mature enough. (1) Should we
remove the summary from StdLibraryFunctionsChecker when that happens? (2)
Or should we have a declaration that ranges and nullability are checked
with summaries while more specific things are checked in their respective
checkers? (3) Or the specialized checkers could be dependencies to the
generic StdLibraryFunctionsChecker, so any bug related to e.g. popen is
prioritized to StreamChecker?

My other goal would be to make it possible to add argument constraints (or
branches/cases) to any library functions. These libraries may never be
modeled in the analyzer. In this case the above problem is non-existent.
Perhaps, we should divide the checker to two different checkers once we
reach that point, shouldn't we? We are very close to
rename StdLibraryFunctionsChecker to LibraryFunctionsChecker anyway by now.

There is more. In `evalCall` if a checker returns true then that function
is no longer processed by any subsequent checkers. That is the case with
pure functions in StdLibraryFunctionsChecker. In this case, however, it
would be anarchy if another checker also returns true from its own evalCall
callback. Only one can rule. It would be great if we could enforce that no
two checkers evaluate the same function this way. But I don't see any clear
solution to achieve that right now, this is really challenging.

Thanks,
Gabor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200625/dca94823/attachment.html>