Skip to content

Commit 38dcab9

Browse files
authored
Rollup merge of rust-lang#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](playable-tech/esp-idf@c5b297a) - ~~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](rust-lang#125271 (comment)) here.
2 parents 567096d + ce3db1b commit 38dcab9

File tree

1 file changed

+7
-9
lines changed

1 file changed

+7
-9
lines changed

std/src/sys/pal/unix/alloc.rs

+7-9
Original file line numberDiff line numberDiff line change
@@ -59,10 +59,9 @@ unsafe impl GlobalAlloc for System {
5959
}
6060

6161
cfg_if::cfg_if! {
62-
// We use posix_memalign wherever possible, but not all targets have that function.
62+
// We use posix_memalign wherever possible, but some targets have very incomplete POSIX coverage
63+
// so we need a fallback for those.
6364
if #[cfg(any(
64-
target_os = "redox",
65-
target_os = "espidf",
6665
target_os = "horizon",
6766
target_os = "vita",
6867
))] {
@@ -74,12 +73,11 @@ cfg_if::cfg_if! {
7473
#[inline]
7574
unsafe fn aligned_malloc(layout: &Layout) -> *mut u8 {
7675
let mut out = ptr::null_mut();
77-
// We prefer posix_memalign over aligned_malloc since with aligned_malloc,
78-
// implementations are making almost arbitrary choices for which alignments are
79-
// "supported", making it hard to use. For instance, some implementations require the
80-
// size to be a multiple of the alignment (wasi emmalloc), while others require the
81-
// alignment to be at least the pointer size (Illumos, macOS) -- which may or may not be
82-
// standards-compliant, but that does not help us.
76+
// We prefer posix_memalign over aligned_alloc since it is more widely available, and
77+
// since with aligned_alloc, implementations are making almost arbitrary choices for
78+
// which alignments are "supported", making it hard to use. For instance, some
79+
// implementations require the size to be a multiple of the alignment (wasi emmalloc),
80+
// while others require the alignment to be at least the pointer size (Illumos, macOS).
8381
// posix_memalign only has one, clear requirement: that the alignment be a multiple of
8482
// `sizeof(void*)`. Since these are all powers of 2, we can just use max.
8583
let align = layout.align().max(crate::mem::size_of::<usize>());

0 commit comments

Comments
 (0)