5 ms·

An old school c programmer wants to know if there's a Rust idiom for recovering gracefully from failed allocations (i.e., when malloc returns NULL). Otherwise,

An old school c programmer wants to know if there's a Rust idiom for recovering gracefully from failed allocations (i.e., when malloc returns NULL). Otherwise, what good is a type safe program that crashes due to a heap overflow? If this is the wrong kind of question, I'm listening.

steveklabnik 9y ago
Rust's standard library assumes that allocation will not fail. That's just a library; the language doesn't inherently know things about heap allocation. You can always call an alllocator directly and look at what it returns. Furthermore, we're working on an allocator interface that you could use with stdlib stuff that would let you handle it. The TL;DR is basically "if you want to, you can. It's going to be even easier in the future."
- gpm 9y ago
  I'd also imagine that a allocator that returned a Result type would be quite ergonomic. Though you'd have to re-implement any datastructures that you wanted to use.
  - FreeFull 9y ago
    You would probably want to be really careful about avoiding any sort of allocation in the error case, though.
bryanlarsen 9y ago
Where are you using this? Embedded? By default Linux is set to over commit memory, so malloc always be succeeds even if you're out of memory.
- jjnoakes 9y ago
  Not if process limits are set.
- SeanDav 9y ago
  > " By default Linux is set to over commit memory, so malloc always be succeeds even if you're out of memory." How does Linux handle 1 trillion mallocs of 1MB, on a 8GB system with 500GB hard drive, without failing? There is nothing magic about Linux, it still cannot allocate and use memory which physically and virtually is simply not there.
  - steveklabnik 9y ago
    When overcommit is set, it's not malloc that fails; the OS kills your process. So, checking the result of your allocations will never let you handle this kind of error.
    - rcxdude 9y ago
      Though if the allocation is ludicrously oversized (not sure the threshold, but 2x present memory will do it) it will just straight up fail without over-committing.
- dmpk2k 9y ago
  There are other *nix OSes out there (that don't make the mistake of overcommit by default).
Animats 9y ago
That's a legitimate criticism of a systems programming language. You'd like your OS kernel to never panic on an out of memory condition. (The serious end of the embedded world insists on this.) There are people working on this problem.[1] Core Rust avoids almost all implicit heap allocations that aren't triggered by operations the programmer sees as allocations.[2] But there are many library functions which allocate and panic if the allocation fails. [1] https://internals.rust-lang.org/t/notes-interviews-on-fallible-collection-allocations/5619 https://internals.rust-lang.org/t/notes-interviews-on-fallib... [2] https://www.reddit.com/r/rust/comments/69awhl/how_to_know_where_allocations_are/ https://www.reddit.com/r/rust/comments/69awhl/how_to_know_wh...
jwatt 9y ago
> what good is a type safe program that crashes due to a heap overflow Being "safe" is not about preventing any type of crash. It's about preventing exploitable crashes and behavior.

steveklabnik 9y ago

Rust's standard library assumes that allocation will not fail. That's just a library; the language doesn't inherently know things about heap allocation. You can always call an alllocator directly and look at what it returns. Furthermore, we're working on an allocator interface that you could use with stdlib stuff that would let you handle it. The TL;DR is basically "if you want to, you can. It's going to be even easier in the future."

gpm 9y ago
I'd also imagine that a allocator that returned a Result type would be quite ergonomic. Though you'd have to re-implement any datastructures that you wanted to use.
- FreeFull 9y ago
  You would probably want to be really careful about avoiding any sort of allocation in the error case, though.

bryanlarsen 9y ago

Where are you using this? Embedded? By default Linux is set to over commit memory, so malloc always be succeeds even if you're out of memory.

jjnoakes 9y ago
Not if process limits are set.
SeanDav 9y ago
> " By default Linux is set to over commit memory, so malloc always be succeeds even if you're out of memory." How does Linux handle 1 trillion mallocs of 1MB, on a 8GB system with 500GB hard drive, without failing? There is nothing magic about Linux, it still cannot allocate and use memory which physically and virtually is simply not there.
- steveklabnik 9y ago
  When overcommit is set, it's not malloc that fails; the OS kills your process. So, checking the result of your allocations will never let you handle this kind of error.
  - rcxdude 9y ago
    Though if the allocation is ludicrously oversized (not sure the threshold, but 2x present memory will do it) it will just straight up fail without over-committing.
dmpk2k 9y ago
There are other *nix OSes out there (that don't make the mistake of overcommit by default).

Animats 9y ago

That's a legitimate criticism of a systems programming language. You'd like your OS kernel to never panic on an out of memory condition. (The serious end of the embedded world insists on this.) There are people working on this problem.[1] Core Rust avoids almost all implicit heap allocations that aren't triggered by operations the programmer sees as allocations.[2] But there are many library functions which allocate and panic if the allocation fails. [1] https://internals.rust-lang.org/t/notes-interviews-on-fallible-collection-allocations/5619 https://internals.rust-lang.org/t/notes-interviews-on-fallib... [2] https://www.reddit.com/r/rust/comments/69awhl/how_to_know_where_allocations_are/ https://www.reddit.com/r/rust/comments/69awhl/how_to_know_wh...

jwatt 9y ago

> what good is a type safe program that crashes due to a heap overflow Being "safe" is not about preventing any type of crash. It's about preventing exploitable crashes and behavior.