Hacker News Reader

Comment by monocasa | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

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.

> You can't push_str() under cfg(no_global_oom_handling) either

Thanks for the clarification. I had totally missed the point.

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?

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).

You could definitely show all the lines that might allocate statically.

I'm pretty sure catching this in all cases would involve solving the Halting Problem.

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.

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

    fn maybe_alloc() -> Vec<usize> {
        if collatz_conjecture_is_true() {
            vec![42]
        } else {
            vec![]
        }
    }

    fn main() {
        let v = maybe_alloc(); // Does this allocate?
    }

You would just assume it does. Really you want to detect all places that might allocate.

You are right. It’s definitely possible if you accept false positives.

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?”

You can absolutely statically determine where allocations happen.

You can't know for sure if all of those places are reachable in a running program, but that's not necessary to solve this problem.

Reply on news.ycombinator.com