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

[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);
----------------
huixie90 wrote:

I think I am convinced this is UB-free now. My question still remains: is this what we want to do? The documentation of the os wait says, in case we are requesting a 4 bytes wait, the "lower 4 bytes" of this `uint64_t` is used 
https://developer.apple.com/documentation/os/os_sync_wait_on_address_with_timeout#parameters

if we use `memcpy` to copy the 4 bytes to this `uint64_t`, does the resulting "lower 4 bytes" of `__value` depend on the endian? well in practice it is not an issue as both x86 and arch64 has little endian. but the fact i had to go through this thought process makes me wonder if we should do it differently

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