[libcxx-commits] [libcxx] [libc++][hardening] Categorize assertions that produce incorrect results (PR #77183)

[Konstantin Varlamov via libcxx-commits]

================
@@ -283,6 +283,14 @@
 // - `_LIBCPP_ASSERT_COMPATIBLE_ALLOCATOR` -- checks any operations that exchange nodes between containers to make sure
 //   the containers have compatible allocators.
 //
+// - `_LIBCPP_ASSERT_ARGUMENT_WITHIN_DOMAIN` -- checks that the given argument is within the domain of valid arguments
----------------
var-const wrote:

I spent a lot of time thinking how to name this category and I can't say I'm completely satisfied with the result. The criteria I'm using is roughly "The given arguments make it impossible for us to produce the correct result; returning a nonsensical value doesn't cause any immediate runtime issues within our library, but is likely to lead to a bug, potentially a serious one, in the user code once they access the value".

Intuitively, it does seem like a well-defined concept to me. I think the difficulty I experienced with the naming is due to the fact that our naming scheme mostly describes the expectation for the condition, whereas my intuitive definition focuses on the outcomes of violating the condition. It's not an issue when there is a direct one-to-one correspondence between the two, which I think is the case for most other category names (e.g. `valid-element-access` arguably describes both the cause and the effect because there is a direct correspondence between them). This, however, is more of a many-to-one relationship. An obvious name would be `valid-argument`, but since we're mostly checking user-provided arguments, this really applies to every category we have -- for example, `valid-element-access` is ultimately also a check for a valid argument. I still think that a naming scheme based on the outcomes being prevented would be easier to work with, but it goes against the fact that _asserting_ asserts the successful case, not the failing case.

While `argument-within-domain` is not _that_ different from `invalid-argument`, it seems a little more specific to me and also seems to apply to the existing usages pretty well (it is, of course, inspired by `std::domain_error`). I thought about something like `valid-argument-fallback` or `nonspecific-valid-argument` but it doesn't really help better express the part I consider the more important one, giving the user back an incorrect result (or object, which can be seen as a result of running a constructor).

Another aspect to consider here is how easy it would be for a library developer, especially someone who is new to libc++, to use the new category in the intended way.



https://github.com/llvm/llvm-project/pull/77183