Skip to content

Commit

Permalink
Rollup merge of rust-lang#125271 - RalfJung:posix_memalign, r=working…
Browse files Browse the repository at this point in the history
…jubilee

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.
  • Loading branch information
workingjubilee committed May 25, 2024
2 parents 8f00197 + 3c2d9c2 commit 508d5e4
Showing 1 changed file with 7 additions and 9 deletions.
16 changes: 7 additions & 9 deletions library/std/src/sys/pal/unix/alloc.rs
Original file line number Diff line number Diff line change
Expand Up @@ -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",
))] {
Expand All @@ -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>());
Expand Down

0 comments on commit 508d5e4

Please sign in to comment.