Allow CStr and CString types to be used with no_std

[clarfonthey]

Embedded code may interact with C and thus may find these types useful. It'd make sense to allow usage of CStr in libcore and CString in liballoc.

Of course, right now due to the way implementations work in the standard library it may not be possible to include CStr in libcore. However, moving it to liballoc is still a step up.

[kennytm]

Including CStr in libcore means the target-dependent type c_char will need to be in libcore as well.

[clarfonthey]

@kennytm in that case, it would make sense to just move the entire os::raw module over to libcore. I'd probably rename it, though, and put it as a submodule of ffi.

[kennytm]

@clarcharr libcore should not contain any public platform-dependent items (liballoc is also platform-independent at the moment). If we move CStr and std::os::raw out, it's better be an independent libffi crate.

[nodakai]

Can we not make a pragmatic compromise of moving the meat of CStr (with c_char replaced by u8) to libcore and retain compatibility by providing a facade with c_char in libstd? I doubt we will ever port Rust to any platforms with CHAR_BIT != 8 (which will still be possible with a customized libcore,) and all operations provided by the current CStr seem to be indifferent with the possible signedness of c_char.

Cf. https://stackoverflow.com/questions/40575116/ C's char, signed char and unsigned char are one and the same ("character") type in the context of aliasing.

[clarfonthey]

Inconsistency I noticed: CStr converts from [u8], which makes it very obvious that we are putting a preference for u8, but it references c_char. I would consider this a bug but I'm not sure if we'd be able to change this, considering how it'd be a breaking change :(

[est31]

Including CStr in libcore means the target-dependent type c_char will need to be in libcore as well.

Why is that a problem? usize as well as isize are in libcore as well, and both of them are target dependent.

[kennytm]

@est31

1. usize and isize are built in primitives, c_char is just a type alias to u8 or i8 depending on #[cfg]. Moving c_char to libcore represents a change in policy (even encoded in a tidy check), which while is currently happening due to VaList, should still be verified whether it's suitable.

2. Just because there's some platform-dependent stuff in libcore (usize and atomics) doesn't mean we want more.

[vsiles]

In the meantime, is anyone aware of a crate which would do this (provide cstr/cstring for no_std situation) ?

[clarfonthey]

Personally I think that the methods involving *const c_char should be removed (i.e. deprecated) in favour of ones that reference *const u8. That way, people who want to cast to *const c_char still can, but we can at least move CStr to core and CString to alloc without the platform-specific types.

[gnzlbg]

We can't expose CStr in libcore. libcore is by definition platform independent, but CStr is a string of C chars, which are by definition platform-dependent types. In C, char is a different type than signed char and unsigned char, and in particular, the signedness of char is implementation defined (platform specific).

What we could do is move CStr to libc, which is IMO where it belongs. libstd can then re-export libc's CStr in std::ffi::, and libc could re-export libstd's CStr when libstd is available (that is, when libc/use_std is enabled). That way both libc::CStr and std::ffi::CStr would be the same type.

The main reason not to move CStr to libc right now is that it is not FFI safe. Until that's fixed, it's probably dangerous to move it to libc since that might encourage people to use it in C FFI and that would be instant undefined behavior.

[cramertj]

libcore is by definition platform independent

I don't see how this is true-- as pointed out above, libcore contains usize and isize which both vary by target.