[abendstolz]

Can you elaborate as to why "his isn't how you'd do things in userspace, but, this isn't userspace so fine" holds?

Naive me - not a kernel dev at all - would argue that returning Result<Memory, AllocationError> is always better, even for userspace because it would allow me to additionally log something or gracefully deal with this.

Even if I don't want to deal with it, I could just `.unwrap()` or `.expect('my error message')` it.

Note: I am not trying to be snarky here, I genuinely don't know and would like to.

If answering this is too complex, maybe you can point me in the right direction so I can ask the right questions to find answers myself? Thanks in any case!

[tialaramex]

> it would allow me to additionally log something

If you don't have any memory your allocations are all failing. When you assemble the log message, the allocation needed to do that fails. Bang, double fault.

Now, often people don't really mean they want allocations to be able to fail generally, they're just thinking about that code they wrote that reads an entire file into RAM. If it was a 100GB file that would be a bad idea. But the best answer is: Guard the allocation you're actually worried about, don't ladle this into the fast path everybody has to deal with on every allocation.

[rtpg]

People say that "well if allocations fail all bets are off" but can't you pre-allocate memory for error handling?

Like sit down, figure out all the things you'll want to do on an allocation failure, and once you have determined that you slice a little chunk of memory when you start your app (and maybe _that_ fails and you can't do anything). and when you hit a failure you do your think, then tear stuff down.

[ensiferum]

What if the failed allocation came from a different allocator/heap than from where the allocations for string logging came from?

In general Don't assume anything about your global process state just because one allocator fails.

[abendstolz]

Mhm, thanks.

It never occurred to me (being in non-embedded land) that returning an enum as the error or a &'static str instead of a heap structure like String, could also fail.

Seeing that Result isn't part of core, but of std, this makes sense.

Just to tickle my nerve though: theoretically speaking, with your example, it would work, right?

I couldn't allocate 100GB (because OOM or not even enough RAM to begin with) but it could be that the system can allocate the needed memory for error message just fine.

Very interesting.

[cormacrelf]

Tialaramex answered this in their post already, and you almost answered the question yourself:

> I could just .unwrap() or .expect('my error message') it.

Panicking can allocate. Allocating can fail. Failing can panic. Panicking can allocate. Allocating can fail. You can bite yourself in the ass like a real Ourobouros.

IMO, a prerequisite to using fallible allocation APIs should be attempting to write your own allocator, handling the weird and wacky problem of initialising a data structure (for the heap) in such a way that if it fails, it fails without allocating but leaves some hint as to what went wrong.

[abendstolz]

Oh, wow, I was under the impression that the error message would be stack only, no heap involved, but as Result is part of the std library and not of core, this totally makes sense.

So for `Rust for Linux` they also need to implement a `Result-like` type that is stack only based to solve this issue, right?

If so, cool, thanks, you just made my day by tickling my learning nerves! :)

[skitter]

AFAIK one other thing to note is that in Linux userspace, malloc (or fork) might succeed, but accessing the memory later can fail because of memory overcommit.