3 ms·

I agree that if you're in kernel space, then you have to be able to recover from allocation failure. However, it's a waste of time for most programs (or librari

I agree that if you're in kernel space, then you have to be able to recover from allocation failure. However, it's a waste of time for most programs (or libraries—most libraries I write can't go into kernel space for various reasons) to try to recover from OOM. Even if not memory-unsafe, it results in untested error handling paths and noisy code. I rarely write Windows-only programs, so I can't rely on OOM handling in my logic. It's much simpler to just have the same OOM story everywhere (crash).

AnIdiotOnTheNet 8y ago
Most zig code still handles OOM via panic. You'd have to go out of your way to somehow make it less safe than that. Dealing with an error by passing it up the call stack (eventually to the panic handler) is actually easier than ignoring it: //kick any error up the call stack var buffer = try allocator.alloc(u8, 500); //in debug builds, assert that this will not fail //in release-fast failure will result in undefined //behavior. var buffer = allocator.alloc(u8, 500) catch unreachable;