<div dir="ltr">Hi,<div><br></div><div>During the review of <a href="https://reviews.llvm.org/D82288">https://reviews.llvm.org/D82288</a> 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.</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>Thanks,</div><div>Gabor</div><div><br></div></div>