Representation of bool, integers and floating points

[nikomatsakis]

This issue is to discuss the memory layout for integral and floating point types:

• bool
• u8..u128, i8..i128
• usize, isize
• f32, f64

For the most part, these are relatively uncontroversial. However, there are some interesting things worth discussing:

• Unlike other types, there are no #[repr(C)] vs #[repr(Rust)] variants here. The size is always fixed and well-defined across FFI boundaries. The types map to their corresponding integral types in the surrounding C ABI.
• Prior discussions ([#46156][], [#46176][]) documented bool as a single byte that is either 0 or 1.
• How is usize intended to be defined on various platforms?
  • the native size of a pointer?
  • the max of various other considerations?
  • other edge cases to consider?
• Rust currently states that the maximum size of any single value must fit in with isize
  - Can we say a bit more about why? (e.g., ensuring that "pointer diff" is representable
• Do we want to discuss signaling NaN at all? Specifically: why is it potentially of concern, and are there things that unsafe authors or other folks need to be aware of? (@gankro, for example, wrote that "NaN masking is unnecessary from LLVM's perspective", but I don't really know what that means. =)

[joshtriplett]

Don't forget u128 and i128.

Another topic: Does FFI code need to use types like libc::uint64_t, or is it safe to just use u64?

[nikomatsakis]

@joshtriplett

Don't forget u128 and i128.

Edited, thanks!

Another topic: Does FFI code need to use types like libc::uint64_t, or is it safe to just use u64?

Good question! I presume it does not, but I'd be curious if there is another side to the discussion.

*Related note: clearly usize and C's unsized are not equivalent, but it's worth stating this explicitly.

[Gankra]

Another topic: Does FFI code need to use types like c_uint64, or is it safe to just use u64?

Much of the rust ecosystem (e.g. webrender and therefore firefox) assumes uint64_t and u64 are the same ABI-wise, and I'm unaware of any reason to prevent that assumption.

How is usize intended to be defined on various platforms?

I believe pointer size is the correct definition but I haven't read the link, so grain of salt

Rust currently states that the maximum size of any single value must fit in with isize

There's no good reason, it's just because llvm has a quirky definition of in-bounds pointer calculations

Do we want to discuss signaling NaN at all? Specifically: why is it potentially of concern, and are there things that unsafe authors or other folks need to be aware of?

Signaling NaNs only merit discussion insofar as the IEEE spec defines some random operations to act differently on them. (e.g. max(sNaN, x) != max(qNaN, x), although iirc this example is regarded as a mistake and is intended to be changed)

Signaling itself is, I think, largely a failed experiment and worth ignoring (soft cc on @stephentyrone in case i'm misremembering)

[hanna-kruppe]

Wrt signaling NaNs, it's more of a question for the (now deferred, cc #8) discussion of valid values. There's a persistent rumor (including, at times, among LLVM contributors) that handling an sNaN or doing certain operations on it will cause a trap or is undefined behavior in LLVM. This is not the case, but I've encountered enough people thinking it's true that I think it would be best explicitly state that signaling NaN are perfectly fine, and thus that all bit patterns are valid floats.

[gnzlbg]

+1 From the point-of-view of just layout, SNaNs are not really that interesting and the easiest thing is to just allow them. AFAIK f32::from_bits(u32) is safe and stable and works for all bit patterns, so we can't really do much about this anyways without potentially breaking some code.

[nikomatsakis]

@gankro

I believe pointer size is the correct definition but I haven't read the link, so grain of salt

The link is to a comment from @gnzlbg and states:

C++ says that usize is an unsigned integer type that can store the maximum size (as returned by mem::size_of<T>/size_of_val/etc.) of a theoretically possible object of any type (including arrays). A type whose size cannot be represented by usize is ill-formed. On many platforms (an exception is systems with segmented addressing) usize can safely store the value of any non-member pointer. In those platforms, usize is a type capable of holding a pointer.

[nikomatsakis]

@gankro

There's no good reason, it's just because llvm has a quirky definition of in-bounds pointer calculations

Do you think we should write down that this is something that is presently true but which may be changed in the future (so unsafe code should not rely on it being true)? It seems like it might affect quite a bit how one writes code.

[nikomatsakis]

(In particular, it seems to imply that it is safe to use isize for "pointer offset" within any one value, which is otherwise not necessarily true, right?)

[Gankra]

I don't think we can ever change it since it's baked into ptr::offset. If we did it would be in a way where negative offsets were a valid very-large-positive offset, so isize would still "work" but be weird.

[Gankra]

also fwiw I think gcc also gets sad with huge offsets

[gnzlbg]

Another topic: Does FFI code need to use types like libc::uint64_t, or is it safe to just use u64?

I think that the bare minimal guarantee here is that the Rust extern "C" function declarations need to use types that match in size and alignment with the types of the C function declaration.

That is, if C uses uint64_t, then you can use u64, libc::uint64_t, or even i64. In particular, libc types are not special. When C uses unsigned, then you need to use a 32 or 64 bit type (or something else) depending on the platform you are targeting. The libc::uint type does this correctly for you, but you don't have to use that.

That would be the bare minimum, and I think that would already be ok since we are just passing bags of bytes here and it is all unsafe anyways. @mw might know whether this can result in any issues due to, e.g., cross-language inlining.

If we wanted to extend this minimum, we could map the C types to the Rust types, e.g. saying that if a C's function declaration uses uint64_t then Rust extern "C" declaration must use a 64-bit wide unsigned integer type. Or if it uses unsigned that the Rust extern "C" declaration must use an unsigned integer type of the same width. But this opens many questions, e.g., is struct A(u64) a 64-bit unsigned integer type that I can use where C uses uint64_t ? What if I apply repr(transparent) to it? I'd rather avoid all this.

I think if we can get by with only the size and alignment requirements, we should. If someone then uses a &T as the return type of an extern "C" function, and the function happens to create an invalid value, then that's UB but that would be covered by a different part of the unsafe code guidelines.