Using the system allocator in a no_std context

[jplatte]

Cross-posting from rust-lang/rust#55660 for increased visibility

What's the story for using the system allocator in a no_std staticlib / binary (one that doesn't want to depend on std because of the networking / threading dependencies std brings with it, but that does depend on libc)? Copying even just one impl GlobalAlloc for System from std (e.g. the unix one) seems very undesireable.

[hellow]

Imagine you're working on an embedded device. The manufacture of that device provides some C libraries and also a malloc and free implementation (imagine it is really complex how to allocate memory on that system).
Instead of reimplementing it in Rust, you can just use the "system allocator" by calling malloc/free of the provided library.
With that allocator you can use String, Vec, and many more.

Does that answer your question?

[dhylands]

Here's an implementation that we used on a CC3200 running FreeRTOS:

cc3200-rs/freertos_alloc at master · fabricedesre/cc3200-rs

Herre's the corresponding rust documentation:
https://doc.rust-lang.org/1.5.0/book/custom-allocators.html

[hellow]

@dhylands

Herre’s the corresponding rust documentation:
https://doc.rust-lang.org/1.5.0/book/custom-allocators.html

1.5.0?!?!
It's quiet old, isn't it? I doubt that it is even up to date

[dhylands]

You are correct, but that was the only example I had.

It looks like this is the way to do things now?
https://rust-embedded.github.io/book/collections/index.html?using-alloc

and I found an implementation here:

GitHub - rust-embedded/alloc-cortex-m: A heap allocator for Cortex-M processors

[jplatte]

No, but my question was answered on the GitHub issue. I specifically am not interested in something for a specific embedded system but rather in using what std already provides as std::alloc::System but without depending on the full standard library (because I would [ideally] like to only depend on libc, not other system libraries the std implementations for different platforms depend on, like Winsock2 on Windows or pthreads on unix-like systems). This is not currently possible, but I've found a much larger issue with no_std anyway that is currently very hard to avoid for me. (namely Incorrect dev-dependency feature resolution · Issue #1796 · rust-lang/cargo · GitHub)