#![no_std] seems quite difficult to use in practice

[jgallagher]

I've had a few conversations on IRC about using #![no_std] in Rust libraries. There are comments around (such as here in html5ever) that using #![no_std] should be used if one wants to write a Rust library that is going to be used from other languages. It's not really clear to me how accurate that recommendation still is currently / will be at 1.0 with the changes to std that have happened over the past months; however, assuming it's still true, I think there are a couple of problems that don't seem to have easy solutions:

• It's really easy to accidentally pull in std by using another crate that links std (html5ever currently has this problem - html5ever uses #![no_std] but depends on phf which links std servo/html5ever#47).
• According to the unsafe docs, a crate using #![no_std] needs to define a few lang_items like stack_exhausted. If two independently-developed crates both define the lang items, you get duplicate name errors when trying to use both simultaneously.

[alexcrichton]

Note that for the second point you don't actually need to define any lang items so long as your'e compiled as an rlib. If you compile as a dylib, staticlib, or an executable you'll be required to provide an impl for all the lang items.

[jgallagher]

Ahh, that helps a lot. I worry more about the first point though. If no_std is a recommended practice for "crates that support use from other languages", will that end up creating a sort of split where some (probably large) percentage of rust crates - the one that do use std - can't be used as dependencies?

[alexcrichton]

I'm not sure I would classify no_std as "recommended practice" per se. Currently no_std serves as a way to disable extern crate std injection, but not a whole lot beyond that in terms of an "official recommendation".

[thehydroimpulse]

/cc me

[arielb1]

There should be an option to make eh_personality and stack_exhausted weak symbols, so that if no rust library is linked, then they would be null, and jumping to them would segfault the program.

[thestinger]

@arielb1: There is absolutely no guarantee of a segfault when dereferencing a null pointer. It only causes that on a subset of platforms due to the zero page being mapped as PROT_NONE. The use case for #![no_std] includes use cases like a kernel where it is not common for this to result in a deterministic crash. It's dangerous undefined behaviour and can be exploited as a memory corruption vulnerability.

[thestinger]

Weak symbols also don't work properly with static linking.

[mahkoh]

Would it be possible for the compiler to provide these functions in a hosted environment with a sane default behavior? E.g., if the the programmer doesn't provide his own functions, they simply abort the process.

[thestinger]

@mahkoh: It can provide the abort behaviour everywhere, because it's provided by an LLVM intrinsic mapping down to a single instruction.

[arielb1]

Kernels will of course have to supply their own version of the failure function, which should be something like linux's panic. I was worried about libraries, which don't want to export a non-weak stack_exhausted etc. symbols (as these will conflict with symbols with the same name from other libraries).

[steveklabnik]

This ticket isn't really actionable, and with changes to the runtime, the details are (somewhat) different overall anyway.