4 ms·

FWIW, this is a little outdated now. If you're willing to bite off nightly, there's cfg(no_global_oom_handling) which will just remove access to the aborting a

FWIW, this is a little outdated now. If you're willing to bite off nightly, there's cfg(no_global_oom_handling) which will just remove access to the aborting allocation API. It came out of the Linux kernel work and their very similar concerns IIRC.

tialaramex 5y ago
If you cfg(no_global_oom_handling) lots of nice things go away. Which is both appropriate - those nice things did in fact depend on global OOM handling - and hopefully likely to keep more people from erroneously believing they can't afford global OOM handling. As an example, ordinarily on Rust this does what it looks like it does: let mut lyrics = "Never was".to_owned(); lyrics += " a cornflake girl"; With cfg(no_global_oom_handling) this can't work, most importantly because the second line is an arbitrary concatenation and therefore allocates, but there is no possible way to signal if it fails.
- AlexanderDhoore 5y ago
  As an embedded C guy this makes me so happy. Yes, that second line allocates and the fact that it is hidden makes me nervous. I want a programming environment that exposes all of the complexity and makes me deal with the consequences.
  - tialaramex 5y ago
    Linus feels similarly, which is why this feature was mandatory to land Rust-for-Linux and why C++ in Linux was never likely to go anywhere.
- Waterluvian 5y ago
  Newbie question: How hard would it be for a text editor to highlight all lines that do or might allocate? Can they be known statically?
  - wizzwizz4 5y ago
    rust-analyzer could probably do it. That information isn't exposed in type signatures, though, so it'd have to have full access to the source of everything and a good understanding of the standard library (and would fail if you added your own “might allocate” by going around the back of the global allocator).
  - 1f60c 5y ago
    I'm pretty sure catching this in all cases would involve solving the Halting Problem.
    - Waterluvian 5y ago
      I think if we wanted a concrete answer you’d be right. But I feel like a static analyzer could clearly identify “this line can allocate” just by knowing what language features can allocate. And for third party library methods “does this function have anything inside of it that could allocate?”
    - oconnor663 5y ago
      If you're allowed to have false positives, it's not so hard. Like "this function allocates if A or B is true" just becomes "this function can allocate". It's not so different from finding functions that can panic.
    - Xylakant 5y ago
      I’m fairly certain that this does not require solving the halting problem. Fundamentally, every line of code can be transformed to the underlying code constructs, and those could be checked for allocations. Doing this in an efficient manner is probably hard, but certainly not impossible
      - umanwizard 5y ago
        fn maybe_alloc() -> Vec<usize> { if collatz_conjecture_is_true() { vec![42] } else { vec![] } } fn main() { let v = maybe_alloc(); // Does this allocate? }
- umanwizard 5y ago
  I’ve been doing Rust full-time for two years and I had no idea you could do this. I’d just have used `push_str` in any case. Giving this up doesn’t seem very impactful and I’d be happy to do so to enable actually useful features.
  - tialaramex 5y ago
    You can't push_str() under cfg(no_global_oom_handling) either I mean, they did warn you: No Global OOM Handling. So, if this mustn't fail, and it might not succeed, therefore it has to be eliminated, a String under cfg(no_global_oom_handling) can't push_str() and it can't reserve() and it can't do a lot of things. Their definitions are conditionally removed from the type. I didn't check, it's possible "something".to_owned() is similarly forbidden, seems like that would allocate memory. Basically if you live in a world where allocating memory for strings, vectors, and other growable types feels extravagant, cfg(no_global_oom_handling) is for you, and if not then maybe you should re-evaluate why you are worried about allocation failures when you are wasting precious heap memory on such data structures.
    - umanwizard 5y ago
      > You can't push_str() under cfg(no_global_oom_handling) either Thanks for the clarification. I had totally missed the point.

tialaramex 5y ago

If you cfg(no_global_oom_handling) lots of nice things go away. Which is both appropriate - those nice things did in fact depend on global OOM handling - and hopefully likely to keep more people from erroneously believing they can't afford global OOM handling. As an example, ordinarily on Rust this does what it looks like it does: let mut lyrics = "Never was".to_owned(); lyrics += " a cornflake girl"; With cfg(no_global_oom_handling) this can't work, most importantly because the second line is an arbitrary concatenation and therefore allocates, but there is no possible way to signal if it fails.

AlexanderDhoore 5y ago
As an embedded C guy this makes me so happy. Yes, that second line allocates and the fact that it is hidden makes me nervous. I want a programming environment that exposes all of the complexity and makes me deal with the consequences.
- tialaramex 5y ago
  Linus feels similarly, which is why this feature was mandatory to land Rust-for-Linux and why C++ in Linux was never likely to go anywhere.
Waterluvian 5y ago
Newbie question: How hard would it be for a text editor to highlight all lines that do or might allocate? Can they be known statically?
- wizzwizz4 5y ago
  rust-analyzer could probably do it. That information isn't exposed in type signatures, though, so it'd have to have full access to the source of everything and a good understanding of the standard library (and would fail if you added your own “might allocate” by going around the back of the global allocator).
- 1f60c 5y ago
  I'm pretty sure catching this in all cases would involve solving the Halting Problem.
  - Waterluvian 5y ago
    I think if we wanted a concrete answer you’d be right. But I feel like a static analyzer could clearly identify “this line can allocate” just by knowing what language features can allocate. And for third party library methods “does this function have anything inside of it that could allocate?”
  - oconnor663 5y ago
    If you're allowed to have false positives, it's not so hard. Like "this function allocates if A or B is true" just becomes "this function can allocate". It's not so different from finding functions that can panic.
  - Xylakant 5y ago
    I’m fairly certain that this does not require solving the halting problem. Fundamentally, every line of code can be transformed to the underlying code constructs, and those could be checked for allocations. Doing this in an efficient manner is probably hard, but certainly not impossible
    - umanwizard 5y ago
      fn maybe_alloc() -> Vec<usize> { if collatz_conjecture_is_true() { vec![42] } else { vec![] } } fn main() { let v = maybe_alloc(); // Does this allocate? }
umanwizard 5y ago
I’ve been doing Rust full-time for two years and I had no idea you could do this. I’d just have used `push_str` in any case. Giving this up doesn’t seem very impactful and I’d be happy to do so to enable actually useful features.
- tialaramex 5y ago
  You can't push_str() under cfg(no_global_oom_handling) either I mean, they did warn you: No Global OOM Handling. So, if this mustn't fail, and it might not succeed, therefore it has to be eliminated, a String under cfg(no_global_oom_handling) can't push_str() and it can't reserve() and it can't do a lot of things. Their definitions are conditionally removed from the type. I didn't check, it's possible "something".to_owned() is similarly forbidden, seems like that would allocate memory. Basically if you live in a world where allocating memory for strings, vectors, and other growable types feels extravagant, cfg(no_global_oom_handling) is for you, and if not then maybe you should re-evaluate why you are worried about allocation failures when you are wasting precious heap memory on such data structures.
  - umanwizard 5y ago
    > You can't push_str() under cfg(no_global_oom_handling) either Thanks for the clarification. I had totally missed the point.