Create a separate libc_types crate for basic C types by Amanieu · Pull Request #1783 · rust-lang/rfcs (original) (raw)

Hm so I may not quite be being clear here, so let me try again! The purpose of the libc crate is to provide the types and definitions of what the underlying platform exposes exactly. That is, it theoretically contains all C types and definitions for interoperating with the underlying system. This implies that a libc_types is not necessary because it's what the libc crate is supposed to do already.

Comments have been made about how libc today "requires too many libraries" or "pulls in too many symbols". This is not an inherent limitation to libc, but rather because libc is being lied to about its platform. The libc crates has been ported to a set of platforms, and it provides absolutely no guarantee of working on any other platform. If you've got a platform that doesn't have libc/librt/libutil then libc has not yet been ported to your platform. If such a platform masquerades as x86_64-unknown-linux-gnu then it's misleading to libc as the libc API is then specifically tailored to what that platform actually is.

The intent of the libc crate design was specifically to avoid crates like libc_types. If the underlying platform in fact has no C library, then the libc crate will expose that and not give you any function delcarations or library linkage, just type declarations. This has not been implemented in libc yet, but that's just because an effort hasn't been made just yet to do so.

Does that make sense? This is what I mean by the alternative above of just emptying libc of function declarations and just having types for these sorts of platforms. For example I could imagine an alternative to this RFC along the lines of:

If cfg(target_os = "none"), then the public API of the libc crate will only be the standard C type definitions.

That is, if cfg(target_os = "none"), then the libc crate looks exactly like the libc_types crate being proposed here.

@FenrirWolf

I think the motivation here is that the libc crate in its current form expects that your target has a full and complete version of glibc or musl available, and that is not always the case with embedded systems.

It does indeed! I explained this above, but to reiterate here this is not a limitation of the libc crate. The libc crate has only been ported to platforms with libraries like glibc/musl, it just hasn't been ported to any other platforms (but it certainly can be!)

Let's say your target has a toolchain based on a minimal version of libc like newlib. If you try to link the crate solely for its type definitions, you will fail at compile-time if target_os = none (as there are missing typedefs for the none case).

These problems are all indicative of the work has not been done to port libc. That work can certainly be done, and it can be done at any time in the libc crate. Attempting to masquerade as a different platform and then seeing failures to me isn't a reason to abandon the libc crate entirely.

Why not ship a no_std crate on crates.io that has these types?

That's what he's proposing.

To clarify, this crate is being proposed to ship with the distribution, not on crates.io. Shipping a crate on crates.io doesn't require an RFC.