30
Heapless (data structures for embedded) v0.9.1 has been released! (blog.rust-embedded.org)
submitted 1 year ago by to c/rust@programming.dev
11 comments fedilink hide all child comments
 

This releases includes some pretty nice improvements to the usage of the crate.

If you want to know how the View types I talk about in the release post are built, take a look at my post from back when I contributed them:

https://sgued.fr/blog/heapless-howto/

you are viewing a single comment's thread
view the rest of the comments
[–] 1 point 1 year ago (2 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).

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 1 year ago* (1 child)

    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

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 2 points 1 year 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.)

  • permalink
  • fedilink
  • source
  • parent