Are allocators allowed to panic / unwind?

[5225225]

It was a safety requirement that they don't for GlobalAlloc.

Should unsafe code need to deal with allocators unwinding (as opposed to aborting or otherwise halting the program)?

[Amanieu]

rustc now has better support for dealing with nounwind functions than when GlobalAlloc was originally implemented. Attempting to unwind from the global allocator will abort the program instead of causing undefined behavior.

[Lokathor]

And ideally the allocator would always return null rather than trying to panic and unwind.

[miobrado]

Can allocator return an enumerated value (Ok holding the allocated buffer, or Error in case of allocation failure)?

Makes no sense to panic or halt because some applications use multiple allocators for different purposes within the same application e.g., to limit memory usage by a specific component, so it's expected for some of the allocators to potentially run out of memory. This should not result in app failure, but with graceful out of memory condition handling by the component that ran out of memory, while the rest of the application continues working unaffected.

[CAD97]

Allocators can of course still return null indicating that allocation failed.

[berkus]

Allocators can of course still return null indicating that allocation failed.

What about architectures (MCU) where nullptr is a valid RAM address?

(Would be much better to return a Result<> imo)

[Lokathor]

Null is never valid for pointers at the rust level. The alloc API is already specified to use null as the failure return value, and other pointer operations are already forbidden from using null.

If you need to use a null pointer you need inline assembly