[libcxx-commits] [PATCH] D156181: [libc++] Categorize mdspan assertions, and move assertions tests

Christian Trott via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Mon Jul 24 17:47:17 PDT 2023


crtrott added inline comments.


================
Comment at: libcxx/include/__mdspan/mdspan.h:191
   _LIBCPP_HIDE_FROM_ABI constexpr reference operator[](_OtherIndexTypes... __indices) const {
-    _LIBCPP_ASSERT_UNCATEGORIZED(__mdspan_detail::__is_multidimensional_index_in(extents(), __indices...),
-                                 "mdspan: operator[] out of bounds access");
+    // Note the standard layouts would also check this, but user provided ones may not, so we
+    // check the precondition here
----------------
var-const wrote:
> Is there any case where if we don't do the check inside `layout_left`/`layout_right`, this assertion in `mdspan` would not catch it?
Only if one would use layout_left/right on for their own data structure. For example mdarray will use reuse the layouts, and a user implemented version of that, or for example a user implemented "matrix_type" may not itself check. Generally I do expect the layouts to be used in such types, since its useful machinery beyond mdspan. The reason not to use mdspan in that case is that users may want value semantics of a matrix type, so they just store say a double[16] and a layout_left::mapping<extents<char, 4, 4> or so. 

So the philosophical question is whether we should make the machinery for implementing such types access safe in hardened mode or not. I do believe there is value to doing so and promising essentially that stuff like the standard layouts are safe in hardened mode to be used on their own. But I am not dead-set on it. 


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D156181/new/

https://reviews.llvm.org/D156181



More information about the libcxx-commits mailing list