steakhal added a comment. In D159107#4630573 <https://reviews.llvm.org/D159107#4630573>, @donat.nagy wrote:
> I don't think that the `&arr[N]` issue is too serious: we can just increment > the array extent when the parent expression of the array subscript operator > is the unary operator `&`. If the past-the-end pointer ends up dereferenced > later, the current code is sufficient to report it as a bug (as the checker > monitors all dereferences). My instinct suggests that there is more behind the curtain. For example, on an expression `&arr[N]` (of type `int arr[10]`), we would constrain `N`. We could say that we allow the one before and one after elements, thus introduce a constraint: `N: [-1, 11]`. This `-1` later could participate in casts, and end up interpreted as a really large unsigned number. I should also think about how would we detect off-by-one errors, which is a common category. > I'd be happy to see (a slightly extended variant of) this commit merged, > because I could provide much better warning messages if I can access the > concrete subscript/dereference operations. Of course if you don't have time > to work on this I can put this up for review myself (probably after your > other commits are handled). The thing is, that I only have this week, aka. 1.5 days before I leave for vacation. :D In the future, (no ETA), we likely come back to the Juliet improvements. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D159107/new/ https://reviews.llvm.org/D159107 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
