[PATCH] D86870: [analyzer] Add more tests for ArrayBoundCheckerV2
Gabor Marton via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Tue Sep 1 02:56:18 PDT 2020
martong added inline comments.
================
Comment at: clang/test/Analysis/out-of-bounds-false-positive.c:34
+
+void symbolic_uint_and_int0(unsigned len) {
+ (void)a[len + 1]; // no-warning
----------------
steakhal wrote:
> martong wrote:
> > steakhal wrote:
> > > martong wrote:
> > > > Hmm, this seems to be quite redundant with the `size_t` tests. Why is it not enough to have test for one unsigned type?
> > > > Are you trying to check for overflow errors? Then I'd expect to have indexes around UINT_MAX and so on.
> > > >
> > > > Same comment applies to the tests with the signed types.
> > > In the current implementation - and in any implementation of the checker logic will have to deal with //integral-promotion// during the //simplification// of the //array indexer expression// and the given //extent//.
> > > All of these can have different signess and bitwidth which makes the implementation quite tricky.
> > >
> > > In fact, this resulted in the bug, which this patch-stack aims to fix.
> > > I'm gonna highlight the related parts in the refactoring patch if you think it helps.
> > Okay, makes sense.
> >
> > It's just very painful to have code repetitions, even in the test code. In gtest unittests we can have tests with type parameters to avoid this kind of repetition. But I guess, there is no way to get rid of this repetition in lit tests.
> You can imagine duplicating all of this several times, since the constant in the subscript expression could also have different types, such as: `unsigned`, `long`, `unsigned long`, etc. Potentially uncovering bugs.
> However, I was reluctant to add those as well :|
>
> I could introduce a macro, to expand these - but IMO macros in tests ehh. probably reduces readability.
Macros, ehh.
Could it work if we instantiated a test function template with the types as parameters? AFAIK, we analyze all instantiations as top level. The problem seems to be with the `-verify` and matching the `expected-warning` for each instantiation...
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D86870/new/
https://reviews.llvm.org/D86870
More information about the cfe-commits
mailing list