Make libc build on unknown platforms.

[le-jzr]

Currently, when building on an unknown platform, the build fails because the types c_long, c_ulong, c_char and wchar_t aren't defined anywhere, but are used. This patch adds a fallback definition of c_char (it has no effect on ABI, so both variants are safe), and masks the function declarations that use the remaining types.

[alexcrichton]

Hm could you elaborate on the motivation for this? If libc doesn't have a platform, how can it pick types that it knows are correct?

[le-jzr]

Motivation should be self-explanatory. Bare metal targets and custom operating systems should be able to build the crate. Explicitly adding support for every toy system out there is infeasible, and needing to fork the library in order to affirm that short is i16 and int is i32 is tiresome.

I can't be sure that there aren't target out there where short is more than 16-bit or where int is not 32-bit, but it sounds too inconvenient to be true.

An alternative would be to add an option for systems that are unknown in all regards except that they follow System V ABI. I don't think the target specification format has any field that says "System V compatible C ABI", and if it does, I don't know how to conditionally compile on it.

[le-jzr]

Actually, it would be much better if the flexible target specification just flat out defined the sizes of standard C types, and this crate used the information. But again, I don't know how to go about making that happen.

[alexcrichton]

Hm ok that makes sense for not wanting to fork libc for all possible toy platforms. That being said though this doesn't feel quite right to me in that in my mind it doesn't make sense for libc to target an unknown platform because the whole point of libc is to target the platform being compiled for (and providing a definition of what the "support library" looks like).

This may just mean that we need to pick a name for a "commonly supported platform" where it's "what you normally want" with sizes and whatnot (along with functions/etc)

[alexcrichton]

I'm going to close this for now as I don't think this is the route we want to take for this scenario.

[le-jzr]

I'm ok with that. I'll get back to this eventually, but for the moment my priorities shifted elsewhere.