[libcxx-commits] [libcxx] [libc++] Use public os_sync API instead of private __ulock on newer Apple platforms (PR #182947)

[Nikolas Klauser via libcxx-commits]

================
@@ -90,6 +95,30 @@ static void __platform_wake_by_address(void const* __ptr, bool __notify_one) {
   _LIBCPP_FUTEX(__ptr, FUTEX_WAKE_PRIVATE, __notify_one ? 1 : INT_MAX, 0, 0, 0);
 }
 
+#elif defined(__APPLE__) && defined(_LIBCPP_USE_OS_SYNC)
+
+template <std::size_t _Size, class MaybeTimeout>
+static void __platform_wait_on_address(void const* __ptr, void const* __val, MaybeTimeout maybe_timeout_ns) {
+  static_assert(_Size == 8 || _Size == 4, "Can only wait on 8 bytes or 4 bytes value");
+  uint64_t __value = 0;
+  std::memcpy(&__value, __val, _Size);
----------------
philnik777 wrote:

My mental model is that `memcpy` inspects the object pointed to by `__val` and then implicitly starts the lifetime of `__value` by copying the bytes into it. It of course depends on endianness, just like it depends on the memory layout of the source object, but that simply makes it target-dependent, not invalid. You're allowed to inspect objects and you're allowed to implicitly start the lifetime of objects. Would you have any doubts the following is allowed:
```
uint64_t func(const void* some_data) {
  char buffer[sizeof(uint64_t)];
  memcpy(buffer, some_data, sizeof(uint64_t);
  uint64_t ret;
  memcpy(&ret, buffer, sizeof(uint64_t));
  return ret;
}
```

The current code simply does it in a single step instead of two.

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