(c2rust-analyze) Support ptr-to-ptr casts between safely transmutable types, for now limited to same-sized integers

[kkysen]

• Fixes (c2rust-analyze) Handle compatible ptr-to-ptr casts #840

This introduces the concept of equivalent/compatible/safely transmutable types:

c2rust/c2rust-analyze/src/util.rs

Lines 356 to 380 in 2915b8d

	/// Determine if `from` can be safely transmuted to `to`,
	/// which is defined as `*(from as *const To)` being a safe operation,
	/// where `from: *const From` and assuming `*from` already was safe.
	///
	/// Note that this is one-way, and is slightly different from [`core::mem::transmute`],
	/// and more similar to [`core::mem::transmute_copy`].
	///
	/// This forms a non-symmetric (one-way) equivalence relation, named `~` below.
	/// Formally, `A ~ B` iff `*a` and `*(a as *const B)` are safe, where `a: *const A`.
	///
	/// However, safe transmutability is difficult to check completely,
	/// so this function only checks a subset of it,
	/// with these formal rules for all types `A`, `B`:
	///
	/// * `A = B => A ~ B`
	/// * `A ~ B => *A ~ *B`
	/// * `A ~ B => [A] ~ B`
	/// * `A ~ B => [A; N] ~ B`, where `const N: usize`
	/// * `A ~ B => [A] ~ [B; N]`, where `const N: usize`
	/// * `A ~ B => [A; N] ~ [B]`, where `const N: usize`
	/// * `uN ~ iN`, `iN ~ uN`, where `N` is an integer width
	///
	/// Thus, [`true`] means it is definitely transmutable,
	/// while [`false`] means it may not be transmutable.
	pub fn is_transmutable_to<'tcx>(from: Ty<'tcx>, to: Ty<'tcx>) -> bool {

Thus, we can now allow ptr-to-ptr casts between safely transmutable pointee types, whereas previously they were only allowed for equal types. In particular, this enables support for string casts, which are produced by c2rust transpile as b"" as *const u8 as *const core::ffi::c_char, where c_char = i8. Thus, this fixes #840.

New tests are added in string_casts.rs to cover various ptr casts, though some of them crash in the rewriter due to having implicitly inserted MIR statements like implicit &raws, which are inserted with addr_of!s. Thus, for some of these (where it works), there are versions with explicit addr_of!s that succeed end-to-end.

[fw-immunant]

LGTM.

[kkysen]

@aneksteind, I realized I missed the recursive case here, where a ~ b => *a ~ *b for all a, b where ~ means transmutable, so I've added that now. I'm not sure if this is used anywhere in lighttpd, but it makes the definition more sound and easier to reason about and isn't a large change.

[spernsteiner]

It seems odd to declare that usize and *mut u8 are not safely transmutable, when you can safely convert between them using as, and that conversion behaves exactly the same as mem::transmute. But I agree this conversion shouldn't be supported in this PR - usize has nowhere to attach a PointerId, which is basically the same problem we have with general use of void*. Maybe we need a different name for this property?

Also, it would be good to clearly distinguish between the precise logical property, which may be difficult or impossible to check, and the conservative approximation of that property that we use in the implementation. For example, in the trivial functions PR, the precise property is "calls to this function have no effect on pointer permissions in the caller", and the approximation is "there are no raw pointers reachable through the types in this function's signature".

The casts allowed by this PR will require some additional library support during rewriting - there's no way to safely convert &str to &[i8] using only the standard library.

[kkysen]

It seems odd to declare that usize and *mut u8 are not safely transmutable, when you can safely convert between them using as, and that conversion behaves exactly the same as mem::transmute. But I agree this conversion shouldn't be supported in this PR - usize has nowhere to attach a PointerId, which is basically the same problem we have with general use of void*. Maybe we need a different name for this property?

Ptr-to-int transmutes implicitly drop provenance (still being decided) and int-to-ptr transmutes are just UB. They're not safe, and the language I used for this is safe transmutability, so I think we're good here.

See rust-lang/unsafe-code-guidelines#286.

Also, it would be good to clearly distinguish between the precise logical property, which may be difficult or impossible to check, and the conservative approximation of that property that we use in the implementation. For example, in the trivial functions PR, the precise property is "calls to this function have no effect on pointer permissions in the caller", and the approximation is "there are no raw pointers reachable through the types in this function's signature".

I thought I did? Let me check. I at least did in the follow-up PR to this one.

I checked. It's in the documentation here.

The casts allowed by this PR will require some additional library support during rewriting - there's no way to safely convert &str to &[i8] using only the standard library.

Wdym by this? This PR doesn't allow that cast, nor anything to do with &str.

[spernsteiner]

It's in the documentation here.

Ah, got it - the official definition is the bit about whether *(a as *const B) and *(b as *const A) are safe.

Ptr-to-int transmutes implicitly drop provenance (still being decided) and int-to-ptr transmutes are just UB. They're not safe

I haven't read the full thread you linked, but I saw the bit at the end about ptr-to-int transmute dropping provenance, which I believe is the same behavior you get from the safe cast my_ptr as usize. Do you happen to know whether they intend to make mem::transmute::<usize, *mut u8> UB, contrary to the safe cast my_usize as *mut u8?

I guess this is a bit of a moot point, since "safely transmutable" is effectively defined in terms of "whatever the Rust devs decide is well-defined".

Wdym by this? This PR doesn't allow that cast, nor anything to do with &str.

Sorry, I forgot the example was using b"" rather than "". But I think the same point applies. The example b"" as *const u8 as *const core::ffi::c_char will get rewritten into something involving a cast from &[u8] to &[i8]. This operation is well-defined, but std doesn't provide a safe function for performing it (as far as I know). So we'll eventually need to write or import a library that does provide such a function so we can do the necessary rewriting.

[kkysen]

Ah, got it - the official definition is the bit about whether *(a as *const B) and *(b as *const A) are safe.

Yeah.

I haven't read the full thread you linked, but I saw the bit at the end about ptr-to-int transmute dropping provenance, which I believe is the same behavior you get from the safe cast my_ptr as usize. Do you happen to know whether they intend to make mem::transmute::<usize, *mut u8> UB, contrary to the safe cast my_usize as *mut u8?

I guess this is a bit of a moot point, since "safely transmutable" is effectively defined in terms of "whatever the Rust devs decide is well-defined".

The ptr-to-int transmute drops provenance, corresponding to ptr.addr(). That's different from as usize, which is ptr.expose_addr() and preserves provenance. That's why it can't be round tripped back into a pointer, since it has no provence. If it has no provenance, turning it into a pointer is UB since the pointer needs provenance.

See core::ptr::invalid's implementation, which uses transmute precisely because it creates an invalid pointer.

Sorry, I forgot the example was using b"" rather than "". But I think the same point applies. The example b"" as *const u8 as *const core::ffi::c_char will get rewritten into something involving a cast from &[u8] to &[i8]. This operation is well-defined, but std doesn't provide a safe function for performing it (as far as I know). So we'll eventually need to write or import a library that does provide such a function so we can do the necessary rewriting.

It is in core. You can convert safely through CStr:

• from &[u8]: CStr::from_bytes_with_nul
• to *const c_char: CStr::as_ptr

[kkysen]

@spernsteiner, could you take a look at the new separated CastKind handling (4bbb306) if that and the reversion in 720c2fb addresses your comment here: #839 (comment)?

Also, regarding #909 (comment), I'm not sure why #919 is causing that crash related to FIXED. Even without #839 at all, this function

pub fn cast_array_to_ptr_explicit(s: &[u8; 0]) {
    std::ptr::addr_of!(*s) as *const u8;
}

causes master to crash with that same error:

thread 'rustc' panicked at 'building TypeDesc for FIXED pointer requires a related pointee type', c2rust-analyze/src/type_desc.rs:75:5

[spernsteiner]

I'll investigate that panic next week and also take a look at this PR.

[kkysen]

@spernsteiner, I've merged master into this PR after you just merged #945, so that crash is fixed now.

[spernsteiner]

Looks good once the conflict + CI is fixed

[kkysen]

@spernsteiner, given #934 is all approved now, if you plan to merge it tomorrow, I'll wait until that merges to rebase/merge this before merging it into master, as I also want to check if #934 fixes the implicit &raw issue (#909).

[kkysen]

@spernsteiner, given #934 is all approved now, if you plan to merge it tomorrow, I'll wait until that merges to rebase/merge this before merging it into master, as I also want to check if #934 fixes the implicit &raw issue (#909).

Actually, there seem to be issues with #934 running on the string_casts.rs tests, and I think it's issues with #934, so I'm going to merge this PR first and then you can take a look at those issues before merging #934.