Not really. Heapless uses compile time sized backing buffers to implement Vec, string etc with a max upper size. You would typically use heapless with a statically allocated variable, but it is possible to use it on the stack too.

Alloca is different and allocates a dynamically sized block on the stack. Rust doesn't really support alloca, but there is a crate for it that works by calling through a helper function in C: https://lib.rs/crates/alloca

[–] Sivecano@lemmy.dbzer0.com 1 points 2 months ago (3 children)

Awww. why doesn't rust do alloca actually?

[–] Vorpal@programming.dev 1 points 2 months ago (1 children)

Alloca for buffers is generally a bad idea:

If you have an upper known bound, just use that. If you don't you risk stack overflow. Especially on a malicious input.
Alloca optimises poorly (especially with LLVM) since the compiler can't really see how large the stack frame is.

The only reasonable usage I have seen is in the Swift ABI. See this blog post on the topic by a rust compiler developer: https://faultlore.com/blah/swift-abi/ (and even there it is only for some cases that it can be used).

[–] Sivecano@lemmy.dbzer0.com 1 points 2 months ago* (last edited 2 months ago) (1 children)

First of all: alloca is fun.

Second of all: sub is my favourite allocator

Third of all: doesn't llvm literally have an alloca primitive for stack allocation? Like it should handle it, no?

Fourth of all: second point is literally a skill issue idk, especially if your compiler is already proving bounds anyway.

Fifth of all: oh damn, that swift thing looks cool!

Sixth of all: don't take any of this too seriously

Seventh of all: but like actually tho, the nontrivial alloca case not being easily optimizable does not mean that we can't optimize the bounded case, no?

Eight of all: ig rust doesn't really do that kind of low-level access.

Ninth of all: this reminds me of those dynamic stack array warcrime gcc extensions, like shit's craazy, you just size a stack array with an int from stdin.

Tenth level: I suppose the main benefit of this over a stack allocator allocator interface is compile time bounds checks.

Eleventh stage: and maybe it doesn't quite fit the allocator interface?

12th verse: I'm sane, I promise

[–] Vorpal@programming.dev 2 points 2 months ago

12th verse: I’m sane, I promise

Hmm...

As to LLVM and alloca, it doesn't optimise or even work well in practise. Some basic cases work, others are less well tested. There are lots of "should" that "doesn't" in practice in LLVM.

I have not looked at alloca in LLVM myself but from what I have heard from those who are experts on this, it is quite brittle.

Second of all: sub is my favourite allocator

https://docs.rs/bumpalo/latest/bumpalo/ (and bump allocators in general).

Fourth of all: second point is literally a skill issue idk, especially if your compiler is already proving bounds anyway.

In general proving bounds for stack growth is very difficult. With recursion it is undecidable. This follows directly from Rice's Theorem. (This is my favourite theorem, it is nice to know that something is impossible rather than a skill issue.)

(Of course you could have a static analyser that instead of yes/no returns yes/no/don't know, and then you assign don't know to be either of the other classes depending on if you care more about false positives or false negatives. This is how the rust borrow checker works: forbid if it can't prove it is safe, but there will be safe code that it doesn't allow.)

load more comments (1 replies)