[PATCH] D70411: [analyzer] CERT: StrChecker: 31.c

2019-12-09 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added a comment. Ok, so, what should the checker warn on? What should be the intended state machine for this checker? We basically have two possible categories of answers to this question: - "The checker warns every time it finds an execution path on which unintended behavior occurs" -

[PATCH] D70411: [analyzer] CERT: StrChecker: 31.c

2019-12-06 Thread Csaba Dabis via Phabricator via cfe-commits
Charusso added a comment. Please let us measure your examples at first to have a consensus what we would like to see from this checker. In D70411#1769803 , @NoQ wrote: > In D70411#1769628 , @Charusso wrote: > > >

[PATCH] D70411: [analyzer] CERT: StrChecker: 31.c

2019-12-06 Thread Csaba Dabis via Phabricator via cfe-commits
Charusso updated this revision to Diff 232671. Charusso marked 10 inline comments as done. Charusso added a comment. - Make the checker alpha. - Add docs. - Copy-paste @NoQ's test. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D70411/new/ https://reviews.llvm.org/D70411 Files:

[PATCH] D70411: [analyzer] CERT: StrChecker: 31.c

2019-12-04 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added a comment. In D70411#1769628 , @Charusso wrote: > F10966837: str31-c.tar.gz These reports seem to confirm my point. I took a look at first 5 and in all of them the code does in fact ensure that the buffer

[PATCH] D70411: [analyzer] CERT: StrChecker: 31.c

2019-12-04 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added a comment. A while back I had a look into implementing some of the CERT checkers and my vague recollection from these attempts was that it's a bad idea to take CERT examples literally. Most of the CERT rules are explained in an informal natural language and it makes CERT great for

[PATCH] D70411: [analyzer] CERT: StrChecker: 31.c

2019-12-04 Thread Csaba Dabis via Phabricator via cfe-commits
Charusso added a comment. I have picked `curl` as an example, because it has a measurable amount of reports. I still recommend to make this alpha, because the expression-tracking cannot track members, and peoples are using members everywhere. F10966837: str31-c.tar.gz

[PATCH] D70411: [analyzer] CERT: StrChecker: 31.c

2019-12-04 Thread Csaba Dabis via Phabricator via cfe-commits
Charusso updated this revision to Diff 232198. Charusso added a comment. - Tweaking. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D70411/new/ https://reviews.llvm.org/D70411 Files: clang/include/clang/StaticAnalyzer/Checkers/Checkers.td

[PATCH] D70411: [analyzer] CERT: StrChecker: 31.c

2019-11-27 Thread Csaba Dabis via Phabricator via cfe-commits
Charusso marked 2 inline comments as done. Charusso added a comment. The false positive suppression by going backwards on the bug-path of stored reports was a very simple concept, which turned out to be a useless one. The rough idea was that to invalidate every report in a path, and every other

[PATCH] D70411: [analyzer] CERT: StrChecker: 31.c

2019-11-27 Thread Csaba Dabis via Phabricator via cfe-commits
Charusso updated this revision to Diff 231341. Charusso added a comment. - Do not emit a report on re-binding a not null-terminated string, it may will be properly terminated (test added). - Added a test for the necessity of `SValVisitor` in this checker. - Some refactor. CHANGES SINCE LAST

[PATCH] D70411: [analyzer] CERT: StrChecker: 31.c

2019-11-22 Thread Csaba Dabis via Phabricator via cfe-commits
Charusso updated this revision to Diff 230702. Charusso marked an inline comment as done. Charusso retitled this revision from "[analyzer][WIP] CERT: StrChecker: 31.c" to "[analyzer] CERT: StrChecker: 31.c". Charusso added a comment. - Remove the report storing map so we do not traverse

[PATCH] D70411: [analyzer] CERT: StrChecker: 31.c

2019-11-22 Thread Csaba Dabis via Phabricator via cfe-commits
Charusso added a comment. Now I have simplified the checker so we do not need any ASCII-art, I believe. Do we have any better logic than the current implementation to catch when the string is read? CHANGES SINCE LAST ACTION https://reviews.llvm.org/D70411/new/