`no_std` feature

[fiveop]

Given that this is a library for low level programming, it should probably provide a no_std version. I will add (preferably with everyones help) a list what we have to do to get this done.

[kamalmarhubi]

👍 I like this idea. Need to read up on it first though.

[posborne]

Personally, I tend to thing of no_std mostly in the context of projects without an OS (or at least a full-featured os like *nix), which would not be the case here. That being said, maybe I am being short-sighted. Thoughts?

[fiveop]

You might also want to use that feature in order to shrink your executable size. If I understand it correctly, libc added the feature in order to be able to use libc to build the standard library. We certainly do not care for that. I still think the executable size might be a sufficient reason for someone.

So if someone ever shows up and needs this feature or one of us does not have anything better to do, we could (and imho should) implement that feature.

[posborne]

@fiveop Agreed. The executable size argument is valid (at least until LTO works more reliably or is enabled by default).

[kamalmarhubi]

Another motivation: writing libraries in Rust that are meant to be consumed via C ABI from other programming languages. It'd be nice to keep the footprint small in those cases too.

[fiveop]

Somewhat related to this, there might be programs that do not want to link against pthreads. This is currently not possible, because at least sys/signal.rs uses functions that require this.

However, libc does not allow you to disable the relevant bindings currently, so since we depend on libc this is not possible for us to fulfill either.

This is probably a more exotic requirement anyway.

[kamalmarhubi]

there might be programs that do not want to link against pthreads

can you give example use cases? this is intriguing!

[fiveop]

You want to create a single threaded app that is statically linked against libc. In addition you want it to be as small as possible. There is no need to link against libpthread then. However, I do not think that this is possible with libc at the moment.

[Susurrus]

Is this still under active discussion given that it's never been implemented? It sounds like there is a use case that's really yet to coalesce and in the meantime the status quo is fine.

[gnzlbg]

I can't use nix (and need to use libc instead) because it doesn't work with no_std. This means that if I use nix I cannot easily use, amongst others, MemorySanitizer, to test the correctness of safe abstractions over unsafe code.

[asomers]

Are you talking about https://github.com/japaric/rust-san ? That doesn't mention anything about no_std. Why do you need no_std to use it?

[gnzlbg]

The MemorySanitizer requires compiling everything except libc with -fsanitize=memory. If I include std (or core), I would need to recompile those as well, but that is not easily done (without xargo), and takes too long for travis-ci.

So what I do is I use libc with --no-default-features.

[asomers]

Interesting use case @gnzlbg . Would you like to try adding no_std support to Nix?

[gnzlbg]

I have my hands full with stdsimd already and for the crates where I need these I can just use libc already, so it isn't high priority for me. Only a nice to have thing.

FWIW, nix would have to expose libc's use_std feature (and enable it by default), and if nix only uses std facilities exported by core already the following might just work:

// Disable `std` if the `use_std` feature is not enabled
#[cfg_attr(not(use_std), no_std)]
// If `std` is disabled, import `core` as `std` so that all
// code that does `std::` continues to work without
// modifications.
#[cfg(not(use_std))]
extern crate core as std;

Otherwise, adding that and compiling with --no-default-features should reveal all places where nix uses something that's not exported by core, that is, all the places were nix has a hard dependency on std. With that information it might be easier to tell if it is possible to make nix work with no_std at all, and how much work that might be - for all I know adding those lines might be all it takes, plus adding a line to CI that tests nix when built this way.