[libcxx-commits] [PATCH] D112152: [libc++] Unroll loop in std::find_if and define other std::find variants in terms of it

[Arthur O'Dwyer via Phabricator via libcxx-commits]

Quuxplusone added inline comments.


================
Comment at: libcxx/include/__algorithm/find_if.h:90
+
 _LIBCPP_END_NAMESPACE_STD
 
----------------
Idle thought: @fhahn's commentary makes me realize that this PR is uncomfortably adjacent to the ongoing LWG(?) debate over
```
const char *first = "hello world";
const char *last = std::ranges::find(first, std::unreachable_sentinel, '\0');
```
The first question is, because `unreachable_sentinel` by definition can't be reached by incrementing `first` — does that mean that `[first, unreachable_sentinel)` lacks valid-range-ness in the same way as `[first, first-1)` or `[first, nullptr)` lacks valid-range-ness? in which case the above has UB?
Related but perhaps orthogonally, does that mean that `find` in practice should be allowed to read from elements beyond the match as long as they're still in the provided range, e.g.
```
int buf[100];  // uninitialized garbage
buf[0] = 42; buf[1] = 43; buf[2] = 44;
const char *last = std::find(buf, buf+100, 44);  // could this read buf[3] and thus have UB?
```
I think this specific PR isn't doing anything new and dangerous //right now//, but the commentary about "vectorization" and "information that pointers are dereferenceable" and "better optimization" seems very scary to me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112152