Rollup merge of #125271 - RalfJung:posix_memalign, r=workingjubilee

use posix_memalign on almost all Unix targets

Seems nice to be able to use a single common codepath for all of them. :) The `libc` crate says this symbol exists for all Unix targets. I did locally do check-builds to ensure this still builds, but I can't really test more than that.

- For redox, I found indications posix_memalign really exists [here](https://gitlab.redox-os.org/redox-os/relibc/-/merge_requests/271)
- For esp-idf, I found indications [here](https://github.com/playable-tech/esp-idf/commit/c5b297a86f3d65081bc690e81ab53db47b18d31c)
- ~~For horizon and vita (these seem to be gaming console OSes? "Horizon OS" also has some hits for a Facebook product but that seems unrelated), they seem to be based on "newlib", where posix_memalign [seems to exist](https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=3ba2c39fb2a12cd7332ef16b1b3e3df994f7c6f5).~~ Turns out no, this 20-year-old standard POSIX function is unfortunately [not supported](https://github.com/rust-lang/rust/pull/125271#issuecomment-2119221419) here.

1 files changed, 7 insertions, 9 deletions

diff --git a/library/std/src/sys/pal/unix/alloc.rs b/library/std/src/sys/pal/unix/alloc.rs
index 2f908e3d0e9..eb3a57c212b 100644
--- a/library/std/src/sys/pal/unix/alloc.rs
+++ b/library/std/src/sys/pal/unix/alloc.rs
@@ -59,10 +59,9 @@ unsafe impl GlobalAlloc for System {
 }
 
 cfg_if::cfg_if! {
-    // We use posix_memalign wherever possible, but not all targets have that function.
+    // We use posix_memalign wherever possible, but some targets have very incomplete POSIX coverage
+    // so we need a fallback for those.
     if #[cfg(any(
-        target_os = "redox",
-        target_os = "espidf",
         target_os = "horizon",
         target_os = "vita",
     ))] {
@@ -74,12 +73,11 @@ cfg_if::cfg_if! {
         #[inline]
         unsafe fn aligned_malloc(layout: &Layout) -> *mut u8 {
             let mut out = ptr::null_mut();
-            // We prefer posix_memalign over aligned_malloc since with aligned_malloc,
-            // implementations are making almost arbitrary choices for which alignments are
-            // "supported", making it hard to use. For instance, some implementations require the
-            // size to be a multiple of the alignment (wasi emmalloc), while others require the
-            // alignment to be at least the pointer size (Illumos, macOS) -- which may or may not be
-            // standards-compliant, but that does not help us.
+            // We prefer posix_memalign over aligned_alloc since it is more widely available, and
+            // since with aligned_alloc, implementations are making almost arbitrary choices for
+            // which alignments are "supported", making it hard to use. For instance, some
+            // implementations require the size to be a multiple of the alignment (wasi emmalloc),
+            // while others require the alignment to be at least the pointer size (Illumos, macOS).
             // posix_memalign only has one, clear requirement: that the alignment be a multiple of
             // `sizeof(void*)`. Since these are all powers of 2, we can just use max.
             let align = layout.align().max(crate::mem::size_of::<usize>());