Hey! We are somewhat slow in reviews, please understand that.

I do not get why my solution -analyzer-config silence-checkers=core.NullDereference -analyzer-config silence-checkers=core.DivideZero was insufficient, whereas -analyzer-config silence-checkers=core.NullDereference;core.DivideZero is working. One funny thing to note here: LLDB cannot parse "a;b", so that it stops to parse the compiler flags at ;... It is mostly LLDB's fault, but that is why I wanted to avoid the character ;. If I remember right I have picked ; over ,, because the Clang's flag-parser cannot parse ,, but may , is working now. Could you try that and overwrite these silly behaviors, please?

Thanks for the reviews!

• Resolve most of the review comments.
• We really need to specify the design of future checkers.

Okay! Thanks for the review.

• Using getNameAsString().

In D81062#2070823, @NoQ wrote:

This change in the state adds no new information to the state while also burdening the Store with more data to carry and making debugging harder (not only dumps will now have a bunch of explicit bindings, but also these bindings will be much bulkier being derived symbols).

I do not see any debug burden because there were no information to begin the debug. The *new* information occurs at the appropriate place now.

Story: I was looking at the va_list test files and I was very curious why I cannot catch its binding as a struct. So I have checked out an implementation:

typedef struct {
   unsigned int gp_offset;
   unsigned int fp_offset;
   void *overflow_arg_area;
   void *reg_save_area;
} va_list[1];

The answer was: bindArray(). I believe it is convenient to see immediately what we model.

May this is somewhat hand-waving, but this double-binding does not seem useful.

• Refactor.

• Refactor.

In D71155#1854908, @NoQ wrote:

Let's separate CStringChecker improvements into a separate patch and have a separate set of tests for it.

• Refactor.
• State out explicitly whether the Analyzer models the dynamic size.

Way more sophisticated matching: https://reviews.llvm.org/D77745

• Refactor.

I believe it is very strange on a Windows system to have multiple dots in a file. The other issue could be the wildcard /*/ in a path full of \s. The LLVM lit (https://llvm.org/docs/CommandGuide/lit.html) has tons of Windows-related shortcuts, which I have never seen being used, but could be useful.

In D76768#1959285, @ASDenysPetrov wrote:

@NoQ please, review my new patch. I've made some changes from C++ side. It regards replacing backslash to forward-slash in case of Win platform defined.

• Simplify tests.
• Remove dead code, they are far away to being used.
• Add an extra test case.

• Remove the last dead comment.

Thanks for the review, hopefully if I ping @NoQ in every round, it will be green-marked soon.

In D77066#1953280, @Charusso wrote:

getDynamicSizeWithOffset(State, MR, SVB) {
  Offset = State->getStoreManager().getStaticOffset(MR, SVB);
  ...
}

Hm, the MemRegion's offset should be great. I was thinking about if we would store SVal offsets in the Store.

Given that the secondary behavior confuse people I have removed it for now. May if someone introduce a NullTerminationChecker then we introduce such option to warn on insecure calls instant. Thanks @balazske for influencing that change. @NoQ this project had a deadline like half year ago, could you smash that green button please?

• Get rid of the secondary behavior for now.
• Fix review comments.

• Remove the last gymnastic.
• Rebase.

Please avoid to stuff in CheckerContext because this facility should be used by ExprEngine/Store as well.
Let us reword your API: getDynamicSizeWithOffset(ProgramStateRef, SVal, SValBuilder &). Of course we are trying to obtain some buffer-ish size, that is the purpose of the entire API.
I also could imagine something like getDynamicSizeMul(ProgramStateRef, const MemRegion &, const MemRegion &, SValBuilder &), as it is very common.

In D76768#1952674, @ASDenysPetrov wrote:

@Charusso Could you point me where I can find correspondent code which creates dot (graph) files?

Each class has its own dumpJson method which builds up the graph together. The actual dot creation happens in ExprEngine.cpp's struct DOTGraphTraits<ExplodedGraph*>, changed in: D62346

In D73521#1951776, @ASDenysPetrov wrote:

Will this utility affect Visual Studio builds?

• Remove the test of creating a live checker, instead copy over the live checker when the script runs.
• Simplify the script by adding the new package to the end of the file.
• In case of the checkers.rst a non-alpha package is going to be added before the alpha packages.
• According to this change simplify the tests.
• DummyChecker -> ExampleChecker.

In D73521#1923693, @NoQ wrote:

Or is each test run updating the repo? Can we simply make the script do cat DummyChecker.cpp | sed s/DummyChecker/$NAME/g > $NAME.cpp and store the checker only once?

• Fix VLASizeChecker's multi-dimensional array early return.
• So that fix the regression in test misc-ps-region-store.m.
• Fix tests that need regex.
• Add documentation about dumpExtent, dumpElementCount.

"To prevent such errors, either limit copies through truncation or, preferably, ensure that the destination is of sufficient size to hold the character data" - from the rule's page.
Most of the projects are fine truncating by hand because the write happens in somewhat well-bounded strings: IP-addresses, names, numbers... I wanted to make this as practical as possible. Until you are having a null-terminated string without being read, you are most likely fine. Feel free to try this out, probably you would already understand the WarnOnCall option very well.

Thanks for the feedback! Given that it will remain an alpha checker for a long time (~1 year), no one really should use it.

Nice catch, thanks! We have some FIXMEs about MSVC sadly and I was thinking about the same change back in the days.

In D76229#1925363, @f00kat wrote:

In D76229#1925268, @aaron.ballman wrote:

Have you considered making this a static analyzer check as opposed to a clang-tidy check? I think using dataflow analysis will really reduce the false positives because it will be able to track the allocation and alignment data across control flow.

I have never try to write static analyzer before. Okay, I will look at examples of how to work with dataflow.

In D75529#1920796, @vabridgers wrote:

I believe all comments have been addressed. Please let me know if there's anything else required. Thanks

• Try to invoke TableGen, if that fails the user need to specify the path to it.
• The script actually creates a real world (hidden) checker.
  • This checker always made with the build invocation.
  • Its test file always made with the build invocation.
  • Everything else remain as is.
• (calculated: DummyChecker.cpp (100 lines))

In D75529#1912849, @vabridgers wrote:

@Charusso, I cannot find a way to create a test for this change, since this was found using an architecture that supports 16-bit chars.

In D74467#1905416, @NoQ wrote:

In D74467#1905011, @Charusso wrote:

Could you mention how to use this feature in the Summary please?
And something is not right, I have tried it:

Use of uninitialized value $Clang in concatenation (.) or string at /llvm-project/clang/tools/scan-build/bin/scan-build line 1895.

Uh-oh. Does this still show up if you specify --use-analyzer explicitly? Because %scan_build in tests includes this flag because otherwise it has no knowledge of the clang build directory.

sh: 1: : Permission denied

This looks like a separate problem, dunno.

Could you mention how to use this feature in the Summary please?

cd reports
scan-build --generate-index-only .

• Make the tags robust and more unique.

Done, thanks! I will eventually document more. "Some day"... jk.

[Achievement unlocked] 3 green marks.

Thanks everyone! I hope the Analyzer developers start to use the wonderful features from Clang-Tidy.

• Set the size properly.
• Add new debug.ExprInspection patterns: region, size, element count.
• clang-format -i ExprInspectionChecker.cpp.
• Having no idea what is the single regression in tests.

Could you add a test please? We really need tests for every patch.

Cool, that one a lucky one! I think the SymbolRef based world also working, just at some point it could not scale because other systems are region based... For now, it is a much better solution, and this pattern to overload the callback with all the interestingness seems like the standard way of using NoteTags. Thanks!

I believe our path and context sensitive engine is more extensible and precise than checking the source file. Are you sure it scales? I would prefer to tie this information for MemRegions, rather than arbitrary places in the source code. My knowledge is very weak in this checker but I have changed from the Tidy world to the Analyzer to enjoy its benefits. Please enjoy these benefits in your work as well.

I have added green markers to all of your patches as well. I really appreciate the simplification of the MallocChecker. May you would commit it as soon as possible, given that you have nailed what Artem has suggested. Cool^2.

Also... as to why I added so much LLVM_UNREACHABLE annotations

look for a solution better then demonstrated in this patch.

I wish for a third map, something like ReallocationMap. Other than that it is a great direction, I love it. Thanks!

Cool! May it worth to mention the corresponding mail from the mailing list in the Summary: http://lists.llvm.org/pipermail/cfe-dev/2020-February/064754.html

! In D75271#1896223, @Szelethus wrote:
Thinking back, I did have a number of failed attempts to make something a bit less ugly, but the sharp divide between the 2 libraries makes is really-really difficult, and I don't recall alternative solutions being that much better. Either the checker interface gets worse, or the checker registration interface gets so messy that it would severely hurt further improvements in terms of checker dependency development.

In D75271#1895949, @baloghadamsoftware wrote:

It is impossible to use CheckerManager as parameter for shouldRegisterXXX() because CheckerRegistry does not have it. If I add CheckerManager to CheckerRegistry then the printXXX() functions will not work because they do not have CheckerManager at all. This patch does not help in printing error message, see D75171. I need a way to solve 44998 by rejecting the checker if the option is disabled and printing an error message.

PS: The CheckerManager also could serve this behavior as registerXXX() already passing around that manager, but I believe the AnalysisManager supposed to manage the analysis.

I am so sorry to mention, but we need the AnalysisManager to pass around which manages the analysis, therefore it knows both the LangOptions and AnalyzerOptions. Also this entire callback should be removed ideally: it has to be a virtual function defaulting to return true; and if someone needs this feature could rewrite the behavior. I guess there was some debate whether it should be on by default or not, but for a checker writer and future changes this patch shows that how weak this API is.