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

Lines changed: 7 additions & 9 deletions
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)
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy