use posix_memalign on almost all Unix targets

[RalfJung]

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
• For esp-idf, I found indications here
• 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. Turns out no, this 20-year-old standard POSIX function is unfortunately not supported here.

[rustbot]

r? @workingjubilee

rustbot has assigned @workingjubilee.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[RalfJung]

Pinging some of the people listed for these targets, just for awareness.
Cc @ivmarkov @Meziu @nikarh

[workingjubilee]

For horizon and vita

"Horizon" is the name of the Nintendo Switch's system software.

The Vita is just the Vita.

[Meziu]

"Horizon" is the name of the Nintendo Switch's system software.

Horizon also refers to the Nintendo 3DS' firmware/OS. This is actually what (almost) all references of target_os = "horizon" within std are related to, since (afaik) there are no Nintendo Switch targets with std support, but there is an armv6k-nintendo-3ds target with std support.

And yes, Meta did name their Android-VR operating system with the exact same name, but I guess the name wasn't ever marketed with regards to the consoles.

Edit: mentioning @ian-h-chamberlain @AzureMarker for good measure.

[nikarh]

Hi, Vita target does not implement posix_memalign.

where posix_memalign seems to exist.

It's gated in the header under __POSIX_VISIBLE and implementation is per platform. Vita doesn't have an implementation for it. Same seems to be true for horizon.

See

• Vita newlib
• 3DS newlib

[RalfJung]

Ah, damn. :/ Is there an issue tracker where one could ask for better POSIX coverage?

EDIT: I guess that's the mailing list mentioned here.

[RalfJung]

Ironically, "winsup" has posix_memalign.

Also ironically, it does have aligned_alloc. However, looking at the implementation, it seems to make non-power-of-two alignments be UB, which violates the C18 and C23 standards. So maybe we should stay away from that, who knows which other issues it has. (Also it's not supported by libc, so using memalign avoids us having to carry our own declaration.)

[workingjubilee]

"Horizon" is the name of the Nintendo Switch's system software.

Horizon also refers to the Nintendo 3DS' firmware/OS. This is actually what (almost) all references of target_os = "horizon" within std are related to, since (afaik) there are no Nintendo Switch targets with std support, but there is an armv6k-nintendo-3ds target with std support.

Oh, right! We could probably use comments in our code or the platform support documentation to that effect. It is possible these already exist and I just missed it.

[workingjubilee]

To motivate requests like Ralf's somewhat for the target maintainers:

Ah, damn. :/ Is there an issue tracker where one could ask for better POSIX coverage?

People have been implementing more shims for Miri. The more the stdlib flows through standard, well-specified functions, the more Miri doesn't have to have a huge pile of ridiculous hacks. This allows even code for more... interesting platforms, that do basic interop with the system (we're not gonna be simulating games with full rendering to a framebuffer, here...) to benefit from Miri's ability to execute code on the Rust Abstract Machine, either simply as a (slow, but effective) virtual machine, or for its ability to detect violated invariants. Thus if you rely on an upstream C library, and that C library can be persuaded to gain (or simply PRed) extended support for "core" POSIX or Standard C functions... conformant support... this can reduce the amount of maintenance everyone has to do in the future, by making it easier to debug problems with your platform.

Correctly-aligned allocations are pretty important, since people can request arbitrary layouts are allocated with Rust code. They do use that to good effect, and it turns out that posix_memalign is the high-align alloc everyone actually supports pretty well.

[workingjubilee]

Hm, aligned_alloc being UB on bad alignments was permitted by C11, apparently, but C17 corrected this and the return value must be the NULL pointer instead.

[workingjubilee]

Okie-dokie, had been giving it a few days to see if any of the other pinged maintainers had something to say, but we have harder evidence for the Redox and Espressif changes being correct and tier 3 is alas tier 3. Rolling ahead with this.

@bors r+

[bors]

📌 Commit 3c2d9c2 has been approved by workingjubilee

It is now in the queue for this repository.

[workingjubilee]

@bors rollup