ASDenysPetrov added a comment. @chrish_ericsson_atx
Sorry for the late reply. Thank you for reveiwing this. > I think the presence of the initializer list in the test case is not > necessary to trigger the spurious warnings Could you please provide some test cases that you think will uncover other issues. I'll add them to the test set. I also have to mention one point of what this patch do more. Consider next: int const arr[2][2] = {{1, 2}, {3, 4}}; // global space int const *ptr = &arr[0][0]; ptr[3]; // represented as ConcreteInt(0) arr[1][1]; // represented as reg_$0<int Element{Element{arr,1 S64b,int [2]},1 S64b,int}> As you can see, now the access through the raw pointer is more presice as through the multi-level indexing. I didn't want to synchronyze those retrieved values both to be `reg_$0`. I've seen a way to handle it more sophisticatedly. I'm gonna do the same for the multi-level indexing (aka `arr[1][2][3]`). ================ Comment at: clang/lib/AST/Type.cpp:149 + Extents.push_back(*CAT->getSize().getRawData()); + } while (CAT = dyn_cast<ConstantArrayType>(CAT->getElementType())); + return Extents; ---------------- chrish_ericsson_atx wrote: > +1 ================ Comment at: clang/lib/StaticAnalyzer/Core/RegionStore.cpp:1671 if (auto CI = R->getIndex().getAs<nonloc::ConcreteInt>()) { int64_t i = CI->getValue().getSExtValue(); + const Expr *E = InitList->getExprForConstArrayByRawIndex(i); ---------------- chrish_ericsson_atx wrote: > I see where you got the int64_t from -- that's what getSExtValue() returns. > So, if the literal const index value in the expr is greater than LONG_MAX > (but less than ULONG_MAX, of course), this would assert. That seems > undesirable.... That's a great catch! I'll make changes soon. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D104285/new/ https://reviews.llvm.org/D104285 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits