guarantee that char and u32 are ABI-compatible

[RalfJung]

In #116894 we added a guarantee that char has the same alignment as u32, but there is still one axis where these types could differ: function call ABI. So let's nail that down as well: in a function signature, char and u32 are completely equivalent.

This is a new stable guarantee, so it will need t-lang approval.

[rustbot]

r? @Mark-Simulacrum

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

The Miri subtree was changed

cc @rust-lang/miri

[RalfJung]

Cc @rust-lang/opsem

[scottmcm]

We discussed this in the T-Lang triage meeting today.

There was some discussion about whether it'd ever be reasonable to want to do something more optimal here -- maybe passing three chars in a 64-bit register, or using a 24-bit register on a chip that had such a thing.

But as I understood it, the takeaway was that those were considered too unusual to be worth doing, vs the simple rule that people are probably already expecting to be the case (given the size+align match), so let's get confirmation of that:

@rfcbot fcp merge

[rfcbot]

Team member @scottmcm has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm
• @tmandry

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[pnkfelix]

Hey @rust-lang/project-exploit-mitigations , is it okay to guarantee that char and u32 are equivalent in the context of how function calling convention works in the ABI?

[rcvalle]

@pnkfelix thanks for pinging us! I've a few questions so I have a bit more context:

1. I'm assuming that char and u32 will continue to be different types (i.e., can't be used interchangeably in Rust). Is that correct?
2. Is this guarantee for extern "C" functions used with FFI only?
3. Are we expecting that if we declare or define an extern "C" fn func(_: char) it'll be compatible with a C void func(uint32_t arg)?

[RalfJung]

I'm assuming that char and u32 will continue to be different types (i.e., can't be used interchangeably in Rust). Is that correct?

Yes. char also still has the invariant that it must be a valid unicode codepoint.

Is this guarantee for extern "C" functions used with FFI only?

This is a guarantee for all our ABIs.

This is similar to how we e.g. already guarantee that NonZeroU32 and u32 are ABI-compatible.

Are we expecting that if we declare or define an extern "C" fn func(_: char) it'll be compatible with a C void func(uint32_t arg)?

Yes. I am not sure if we are currently officially documenting anywhere that u32 in Rust and uint32_t in C are ABI-compatible, but once that is established, it follows by transitivity that char in Rust and uint32_t in C are ABI-compatible.

[rcvalle]

Thank you for all the information, @RalfJung! Np, I think this should be added to the CFI integer normalization option then. Just let me know by when it needs to be done.

[RalfJung]

Well this PR will hopefully land in around 10 days. :)

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[RalfJung]

@Mark-Simulacrum this is back in your court for review now.
@rustbot ready

[Mark-Simulacrum]

@bors r+

[bors]

📌 Commit b4f3f2a has been approved by Mark-Simulacrum

It is now in the queue for this repository.

[bors]

⌛ Testing commit b4f3f2a with merge e299752...

[bors]

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing e299752 to master...

[CAD97]

ping @rcvalle directly as requested in #118032 (comment)

[rust-timer]

Finished benchmarking commit (e299752): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.9%	[0.9%, 0.9%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.9%	[0.9%, 0.9%]	1

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	6.0%	[6.0%, 6.0%]	1
Regressions ❌ (secondary)	4.9%	[4.9%, 4.9%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	6.0%	[6.0%, 6.0%]	1

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 668.219s -> 668.003s (-0.03%)
Artifact size: 314.10 MiB -> 314.13 MiB (0.01%)