[libcxx-commits] [PATCH] D153816: [libc++][hardening][NFC] Introduce `_LIBCPP_ASSERT_UNCATEGORIZED`.

[Mark de Wever via Phabricator via libcxx-commits]

Mordante added a comment.

In D153816#4453695 <https://reviews.llvm.org/D153816#4453695>, @var-const wrote:

> In D153816#4453166 <https://reviews.llvm.org/D153816#4453166>, @Mordante wrote:
>
>> Is there already a plan which categories you want to make?
>> No objection to this approach, LGTM leaving the final approval to @ldionne.
>
> There are a few specific categories I have planned for short- to mid-term, but not a full plan for everything. The perfect (probably infeasible) state is if the standard library would check all the function preconditions, thus preventing all undefined behavior arising from violated preconditions. I don't think we could list out all the possible categories without going through preconditions of every single library function, which seems overkill at this point -- I think it would be better to focus on the most widely used functions and classes first.
>
> I previously went through `span`, `vector`, `string_view` and the functions in `<algorithm>` and came up with:
>
> - "valid range" -- checks that the given input range is valid (the end is reachable from the beginning);
> - "valid container access" -- essentially checks that the index given to a container is valid. This also affects functions like `vector::back()` (which could be seen as `vector[vector.size() - 1]`. The important thing for this grouping is that validation can be performed using just the information within the container, i.e. without storing anything extra in the iterator;
> - "non-foreign iterator" -- checks that an iterator given to a container does indeed refer to the same container object;
> - "sorted, etc. input" (ad hoc name but captures the intention) -- for algorithms that expect the input to be sorted/partitioned/heapified, checks that the input indeed satisfies that criteria.
>
> I'm sure going through other classes and functions would yield more categories, though I would also reuse these where possible. E.g. I plan to put checking that an `optional` or a `function` is not empty before accessing the stored data into the "valid container access" category (since those classes can be seen as containers holding `0` or `1` element).

Thanks for the info!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153816