Collect discussion points: requirements on the C platform

[gnzlbg]

Almost all layout-related discussions add requirements on the platform in one way or another (e.g. due to repr(C)), and I think it is worth it to have these all in one place.

For example, while discussing the definition of the layout of bool, one definition is that "bool is C compatible" and another one that "bool has size 1 where 0 represents false and 1 represents true". If we require the C platform to have sizeof(_Bool) == 1 both definitions are correct, and if we don't explicitly require that somewhere, we would be implying it later on anyways if we specify that bool is a "proper" C type.

Because not everyone is on Zulip, I'd like to start collecting discussion points for a minimal specification of what the C platform is and what requirements does Rust impose on it in the context of type layout (no calling conventions, etc.). I can send a PR afterwards with more points.

For background, @gankro wrote an excellent document about this: https://gankro.github.io/blah/rust-layouts-and-abis/

Goal of the discussion

The goal is to write down all the current agreed (in other UCG discussions) requirements that Rust has on the C platform and put them in one place to avoid repeating these in all other discussions. This list can evolve over time, and trade-offs on layouts can influence the platform requirements.

Some discussion points

• Is a C platform required or optional?

• If a C platform is optional, can the layout of #[repr(C)] types be platform-dependent ? If so, what's their layout when there is no C platform?

• Which optional parts of a C platform are relevant for Rust? e.g. floats, maybe atomics?

• Does a C platform have to be C standard compliant? This allows us to only specify stricter requirements than what e.g. C17 guarantees.

• @gankro's post mentions the following requirements that go beyond what C17 guarantees:

  • Have 8-bit, unaligned bytes (chars)
  • Have a boolean be a byte, where true = 1 and false = 0
  • Have integers be two's complement
  • Have IEEE 754(-2008?) binary floats, if they exist (e.g. we're comfortable with just disabling floats)
  • Be at least 16-bit (just in terms of pointer size, I think?)
  • Have NULL be 0 (although things may be mapped to 0, but that's messy since references can't be NULL)

  Which points of @gankro's list do we need to settle during the layout discussions? They all look reasonable to me. This could be an initial specification.

• Maybe offtopic: we might have to define / explain what a C platform is. Does C++ requires a C platform? Maybe we could look up how C++ does this.

[Gankra]

Some notes:

C++20 and C20(? "the next one") both appear to be moving to mandating two's complement (but still with undefined overflow because they need that to justify extending int to size_t on 64-bit): https://twitter.com/jfbastien/status/989242576598327296

This is a positive sign that two's complement is indeed the "modern" computing platform.

Of course this just means hairy platforms won't support newer versions of C/C++.

---

I would like to make the following assertion but am not 100% confident about it: I believe that all versions of IEEE 754 are fully forwards/backwards compatible in terms of layout/semantics. Changes like 2008 just tweak recommendations and the set of operations, which are irrelevant for FFI, but does affect how we define core/std ops.

For instance, 2008 officially recommended a more specific signaling NaN encoding (the spec has always specified the signaling bit, but until 2008 made no indication whether 0 or 1 means signaling), which MIPS broke compatibility with itself to conform to, but it's still only a recommendation.

I believe the upcoming(?) version of IEEE 754 is supposed to redefine max/min to remove the janky qNaN/sNaN behaviour that is widely regarded to be a mistake (sNaN in max/min produces qNaN, while qNaN "always loses", making max/min non-commutative, since the position of an sNaN in a chain of max/mins affects the final result).

---

I believe we support platforms with mapped NULL, most notably this is pretty important for GPGPU targets, where programs are generally executing in tiny virtual slices of memory that start at 0.

I think non-zero NULL is way too much of a headache for us to support. Very easy for programmers to be relying on it, especially with NonZero.

---

I believe our only 16-bit target is msp430-none-elf, which is tier 3 core-only, so it's not impossible for us to abandon 16-bit support. But enough legwork has been done that I don't think it would be the end of the world to leave it in... although this does raise the interesting question of the "core platform" vs the "std platform".

---

It would be nice to have some examples of "compelling" or "modern" non-octet-byte platforms. Are they all just DSPs?

[gnzlbg]

So my opinion on @gankro 's list is that is really good.

There are two "nitpicks":

• Be at least 16-bit (just in terms of pointer size, I think?)

This should not be a requirement on the C platform, but a note for clarification: if Rust only supports 16-bit platforms and up then it kind of follows that valid C platforms have at least 16-bit wide pointers.

I think this is a discussion worth having, but maybe we should move it into its own issue?

Have NULL be 0 (although things may be mapped to 0, but that's messy since references can't be NULL)

I think this requirement conflates three things: the need for a bit-pattern to represent a pointer that is not dereferenceable, that the value of this bit-pattern must be the same in C and Rust for types like Option<&T> to be C FFI safe, and what value or values this bit-pattern is actually allowed to take.

I think it would be initially uncontroversial to commit that the C platform has to provide such a bit pattern, and in the Layout of enums discussions to require that this bit-pattern has to match the one used by Option<&T/fn> and NonNull.

We should probably spawn a different discussion to answer questions about what values this bit-pattern is allowed to take, e.g., does it always have to be 0x0? Does requiring it to always be 0x0 actually prevent applications that want to write to the 0x0 address? Is supporting these applications/platforms a trade-off that's worth it? How hard would it be to let targets configure this bit-pattern? etc. I don't know the answer to these questions, but seems like a discussion worth having. It just sounds more to a "validity" issue than to a "layout" issue, so I don't know whether this is a discussion worth starting right now.

[Gankra]

posted a thing on twitter about increasing the core/std split: https://twitter.com/Gankro/status/1059492352493002753

[notriddle]

Saw a thing on lobste.rs about all the odd shapes that the C ABI can take https://begriffs.com/posts/2018-11-15-c-portability.html. I'm sure some of these just won't be supported (sign+magnitude numerics, nine bit words), but I am curious if Rust will be allowed to support tagged pointers or platforms where C strings are EBCDIC (obviously, Rust itself will always be UTF-8).

[hanna-kruppe]

C strings with odd encodings should be fine (as long as they're eight bit), we haven't guaranteed a lot about libc::c_char. A lot of code that talks to C is probably written under the assumption of ASCII, but language-wise I see no reason to "make this our problem". I'm not even sure what we could actually do about it, since C's char type is not just used for strings and the parts of C that do care about character encodings (e.g. isdigit or the interpretation of character literals) are quite far out of scope for us to talk about.