Rust 1.61.0 released

Posted May 26, 2022 10:09 UTC (Thu) by farnz (subscriber, #17727)
In reply to: Rust 1.61.0 released by NYKevin
Parent article: Rust 1.61.0 released

FWIW, in the last 25 years, I've only seen one form of fully justified use of alloca, which is solved by other means in Rust and C++: you use it on "big" systems (ones with stack expansion in the OS) as a way to avoid leaking memory that you know becomes invalid to access at the end of this function. Effectively a way of guaranteeing that regardless of the path through the code, the allocation is freed when no longer in use - which is guaranteed by std::unique_ptr in C++, and by Box in Rust.

Every other use I've seen of alloca has been trivially replaced by a fixed-sized stack allocation - which had the advantage in my embedded days of allowing the compiler to detect statically that we would overflow our stack if we actually used the full allocation.

Rust 1.61.0 released

Posted May 27, 2022 9:00 UTC (Fri) by NYKevin (subscriber, #129325) [Link] (1 responses)

> "big" systems (ones with stack expansion in the OS)

According to ulimit -s, on my Debian (WSL) system, the stack size maximum is 8 MiB, which has to accommodate the entire stack and not just your frame. I assume this value corresponds to getrlimit(2)'s RLIMIT_STACK value, but I'm not writing a whole C program just to check. Given that the rlimit is adjustable, it's entirely possible that some sysadmin has decided to give you a hilariously small stack and you can't actually grow, even if the architecture and OS are fully capable of supporting dynamic stack growth. The net effect of this is that alloca is not actually safe unless the object is tiny, or at least reasonably small, and is in no way a good general-purpose substitute for std::unique_ptr or the like. If you want to ensure that all code paths lead to free, you basically have to use gotos, or a language other than C.

Rust 1.61.0 released

Posted May 27, 2022 14:19 UTC (Fri) by farnz (subscriber, #17727) [Link]

That's the default, yes, but when you're configuring a system for a use case, you can change it. And that was exactly what I saw done - the system was a "big " system for its era, with 256 MiB RAM, and the rlimit increased to 256 MiB so that actually hitting stack overflow meant you were swapping anyway.

It was also surprisingly portable - at the time (1990s), most system administrators would obey the instruction to increase rlimits to match the software the system was bought to run. Nowadays, I expect most sysadmins would be a lot more cautious about obeying that sort of demand.