NoQ added a comment. > My biggest request is: please try to keep this document in sync with reality > so that we don't introduce confusion to the reviews.
Yes, so we'll need the code to incrementally catch up to the document, but I'm absolutely updating this document every time the vision itself changes. ================ Comment at: clang/docs/SafeBuffers.rst:124 + - Array subscript expression on raw arrays or raw pointers, + - unless the index is a compile-time constant ``0``, + - Increment and decrement of a raw pointer with operators ``++`` and ``--``; ---------------- xazax.hun wrote: > xazax.hun wrote: > > Isn't this too restrictive? How about arrays where both the index and the > > size of the array is known at compile time? > > > > Also, what about subscripts in `consteval` code where the compiler should > > diagnose OOB accesses at compile time? > > > > I believe this model can be made more ergonomic without losing any of the > > guarantees. > Small ping on this point. I think there are many code patterns that are > completely safe (i.e., the compiler can diagnose OOB accesses), but the > current model would ban. One example is converting an enum value to string > using an array of string_views. In those cases, both enum consts' value and > the array's size are known at compile time. I think those easy to diagnose > special cases should be permitted to make programming more ergonomic. The > more ergonomic the experience, the faster the adoption will be. Yes, we'll probably add occasional suppressions for known safe cases like this, as long as we're sure we'll diagnose if safety is lost in later code changes. And then document them here. It's probably even reasonable to suppress the warning when the index is a loop counter and the loop bound is known at compile time to be sufficiently small. Though it'll take some work to implement (re-use static analyzer's loop unrolling prerequisites code?) (uh-oh, I thought I sent this reply before the conference) Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D136811/new/ https://reviews.llvm.org/D136811 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
