-
Notifications
You must be signed in to change notification settings - Fork 12.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
avoid using aligned_alloc; posix_memalign is better-behaved #125003
Conversation
Is this rounding even still necessary? Looking at the code, I don't see any indication that the size has to be a multiple of the alignment... but also going back in the history I can't see such a requirement, so maybe I am looking at the wrong thing. Cc @sunfishcode Or... should we just use |
Even emmalloc seems to have posix_memalign, so I think we should just use that. |
That code in wasi-libc is unmodified upstream musl code, so all musl targets presumably behave the same way. On the standards side, the behavior of |
Yeah I since realized this rounding up the size was added only for emmalloc, not for the default wasi-libc allocator.
Correct, it's not been UB since C18 so the old arguments don't apply any more. emmalloc still decides not to support allocations when the size is not a multiple of the alignment, but only when called via aligned_alloc -- as far as I can tell, there's no good reason for that; it supports such requests just fine when they happen via posix_memalign. aligned_alloc also has the strange requirement that the memory must always be sufficiently aligned for types with fundamental alignment that fit into the requested size... I don't see emmalloc actually do that, but the code is too much for me to follow. We don't rely on that, though, so this wouldn't affect us. |
Using (It also seems reasonable that it should now relax that check in |
I tried to find out why we're using a different function on wasi, and I think it's just a historic coincidence. The commit that added wasi support used aligned_alloc, and then later this got merged with the other Unix codepaths but without changing which function gets called where. So there's no indication here that using posix_memalign on wasi would be a bad idea. r? @cuviper |
@bors r+ rollup |
avoid using aligned_alloc; posix_memalign is better-behaved Also there's no reason why wasi should be different than all the other Unixes here.
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
@bors retry |
Rollup of 5 pull requests Successful merges: - rust-lang#125003 (avoid using aligned_alloc; posix_memalign is better-behaved) - rust-lang#125142 (Migrate `run-make/rustdoc-themes` to new rmake.rs) - rust-lang#125146 (Migrate `run-make/panic-impl-transitive` to `rmake`) - rust-lang#125154 (Small improvements to the documentaion of FnAbi ) - rust-lang#125159 (Meta: Allow unauthenticated users to modify `L-*`, `PG-*` and `-Z*` labels) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#125003 - RalfJung:aligned_alloc, r=cuviper avoid using aligned_alloc; posix_memalign is better-behaved Also there's no reason why wasi should be different than all the other Unixes here.
Rustup Pulls in rust-lang/rust#125003 so allocation tests should now work on wasm.
Rustup, aligned heap-allocations on wasm Pulls in rust-lang/rust#125003 so allocation tests should now work on wasm.
Rustup, aligned heap-allocations on wasm Pulls in rust-lang/rust#125003 so allocation tests should now work on wasm.
Rustup, aligned heap-allocations on wasm Pulls in rust-lang#125003 so allocation tests should now work on wasm.
Also there's no reason why wasi should be different than all the other Unixes here.