Add support for cfg(target_family = "none")

[whitequark]

When working on bare-metal platforms, it is often useful to have
Rust code interoperate with existing C code. In such cases,
the target will typically have a minimal, non-standards-compliant
in terms of completeness libc, exporting at least the most basic
library functions like memcpy (this libc could even be provided
via the rlibc crate).

To interoperate with the C code on such platforms, it is useful
to have libc types defined, especially so when using existing
crates that provide bindings to libraries (the motivating
example for this change is the libunwind crate, which binds
to libunwind, which has recently gained1 first-class support
for bare-metal platforms). However, right now, the libc crate
cannot be built for #[cfg(target_family = "none")] because
of missing definitions for basic types such as c_char.

This commit provides a set of reasonable default aliases.
These will likely not be correct for every platform, and should
be refined in the future.

Discuss? I intend this to be a first step.

[whitequark]

To elaborate on the above: what I'd like to have is libpanic_abort and libpanic_unwind building for cfg(target_family = "none"), and libc is a prerequisite for this.

[alexcrichton]

Thanks for the PR! I'm personally pretty hesistant to do this however because the C types in general have no meaning unless a platform is assigned to them. I don't think it's possible for us to interpret a generic "none" platform and assign meaning to these names, as inevitably they will be silently incorrect for a new platform and only get discovered later on down the road.

[whitequark]

How do you propose improving the user experience of libc on bare metal? The current situation requires anyone who needs it to fork libc, which is kind of absurd in long term.

[whitequark]

If clang is able to give me a char for an $ARCH-unknown-none triple, then why shouldn't Rust be able to do so as well?

[alexcrichton]

I'd personally would expect that, yes, a fork of libc per platform. The libc crate is defined as binding to a specific platform, so we can't bind a generic platform that may or may not exist.

[whitequark]

Closing this, but still would like to hear your response wrt clang being able to do so.

[alexcrichton]

Is clang following a standard? Will all other C compilers match what clang does for all integer types? It seems to me that clang must do something or otherwise C isn't usable for a new target, but it's not clear that all other compilers (or the actual platform) would agree with clang in all cases.

[whitequark]

Good question. I don't know the answer to it.