Support no_std

[glandium]

There are multiple use cases for no_std, most of which have no use for errno. But a few use cases involving low-level code that can't use libstd can still use e.g. libc. No libstd means no std::io, which means no errno from there.

Those use cases could be considered niches, and I would totally understand that a small crate for a couple uses in the entire rust ecosystem might not be worth. Being at the beginning of my project, I only need read access to errno, and have copy/pasted the relevant parts for that for now (and only the unix parts for prototyping purposes), but I will eventually need cross-platform and write access as well. To give you an idea how niche my own use case is: I'm reimplementing a malloc() library (namely, mozjemalloc, the allocator in use in Firefox) in rust.

[lambda-fairy]

Thanks for the write-up!

I think the hardest part will be writing the Display instance, since that would require decoding the error message provided by the OS.

On POSIX, we can use core::str::from_utf8. Need to be careful with decoding errors, though. The current implementation replaces errors with U+FFFD; to replicate this in the non-allocating implementation, we will need to call str::from_utf8 in a loop.

As for Windows: there is a non-allocating UTF-16 decoder in the standard library, but it's in the unstable std_unicode crate instead of core. I have filed an issue (rust-lang/rust#49319) to fix this.

There is also the question of whether it's efficient to write the message one character at a time, which is what a naïve implementation using char::decode_utf16 would do. I suspect that it doesn't matter in practice, but the implementer will need to confirm this.

[glandium]

At least for my niche case, I don't care about Display at all. In fact, I wouldn't have a use for it. I'm not entirely sure it's worth worrying about Display until someone that needs the errno crate with no_std actually needs it. Who knows, I might even end up being the only user of this crate with no_std.