ASDenysPetrov added a comment. In D104285#2943449 <https://reviews.llvm.org/D104285#2943449>, @aaron.ballman wrote:
> One thing I think is worth asking in this thread is whether what you're > analyzing is undefined behavior? Technically you are right. Every exit out of an array extent is UB according to the Standard. But in practice we can rely on the fact that multidimensional arrays have a continuous layout in memory on stack. Also every compiler treats `int[2][2]` and `int**` differently. E.g.: int arr[6][7]; arr[2][3]; // *(arr + (2*7 + 3)) = *(arr + 17) int *ptr = arr; ptr[17]; // *(arr + 17) int **ptr; ptr[2][3] // *(*(ptr + 2) + 3) Many engineers expoit this fact and treat multidimensional arrays on stack through a raw pointer (`(int*)arr`). We can foresee their intentions and treat a multidimensional array as a single one instead of a warning about UB. > And when you turn some of these examples into constant expressions, we reject > them based on the bounds. e.g., https://godbolt.org/z/nYPcY14a8 Yes, when we use expicit constants there we can catch such a warning, because AST parser can timely recognize the issue. The parser is not smart enough to treat variables. Static Analyzer is in charge of this and executes after the parser. I think AST parser shall also ignore the Standard in this particular case with an eye on a real use cases and developers' intentions. As you can see there is a bit modified version which doesn't emit the warning https://godbolt.org/z/Mdhhe6Eo9. 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
