Type validation mistreats layout errors

The original problem got fixed by avoiding the broken code paths; this issue now tracks [fixing those code paths](https://github.com/rust-lang/rust/issues/71353#issuecomment-617901923).

### Original issue

In [the `ffi_helpers` crate](https://github.com/Michael-F-Bryan/ffi_helpers) we have a [`Nullable`](https://docs.rs/ffi_helpers/0.2.0/ffi_helpers/trait.Nullable.html) trait which gives you a generic way to do null pointer checks.

```rust
pub trait Nullable {
    const NULL: Self;

    fn is_null(&self) -> bool;
}
```

A user recently reported that the crate no longer compiles on `nightly` (https://github.com/Michael-F-Bryan/ffi_helpers/issues/2) because type validation detects that `std::ptr::null()` and `std::ptr::null_mut()` create uninitialized raw pointers.

```
  Compiling playground v0.0.1 (/playground)
error[E0080]: it is undefined behavior to use this value
  --> src/lib.rs:17:5
   |
17 |     const NULL: Self = std::ptr::null_mut();
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ type validation failed: encountered uninitialized raw pointer
   |
   = note: The rules on what exactly is undefined behavior aren't clear, so this check might be overzealous. Please open an issue on the rustc repository if you believe it should not be considered undefined behavior.

error: aborting due to previous error

For more information about this error, try `rustc --explain E0080`.
error: could not compile `playground`.
```

I can reproduce this [on the playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=6d119e3b2cdbaa82880a469401d73800) with the latest nightly, `1.44.0-nightly (2020-04-19 dbf8b6bf116c7bece298)`.

Is the use shown in that playground example (`*self == Self::NULL` on a `*mut T`) actually UB?

Also, I noticed that calling the `is_null()` method defined on a raw pointer with `<*const T>::is_null(*self)` *doesn't* trigger this error, implying that the problem isn't with declaring a constant that contains a null pointer (`const NULL: Self = std::ptr::null_mut()`), but the fact that we're using it for a comparison. Was this intended, or is it just an oversight in the error detection code?

<details>
<summary>Full example with output</summary>

```rust
pub trait Nullable {
    const NULL: Self;

    fn is_null(&self) -> bool;
}

impl<T> Nullable for *const T {
    const NULL: Self = std::ptr::null();

    #[inline]
    fn is_null(&self) -> bool {
        <*const T>::is_null(*self)
    }
}

impl<T> Nullable for *mut T {
    const NULL: Self = std::ptr::null_mut();

    #[inline]
    fn is_null(&self) -> bool {
        *self == Self::NULL
    }
}
```

```
Compiling playground v0.0.1 (/playground)
error[E0080]: it is undefined behavior to use this value
  --> src/lib.rs:17:5
   |
17 |     const NULL: Self = std::ptr::null_mut();
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ type validation failed: encountered uninitialized raw pointer
   |
   = note: The rules on what exactly is undefined behavior aren't clear, so this check might be overzealous. Please open an issue on the rustc repository if you believe it should not be considered undefined behavior.

error: aborting due to previous error

For more information about this error, try `rustc --explain E0080`.
error: could not compile `playground`.

To learn more, run the command again with --verbose.
```
</details>

CC: @RalfJung because it looks like they were the last person to touch that error message (9ee4d1aadc7f4151193a7f53d1fcbb4fddf40ece).




This issue has been assigned to @jumbatm via [this comment](https://github.com/rust-lang/rust/issues/71353#issuecomment-617128281).

	let place = try_validation!(
	self.ecx.ref_to_mplace(self.ecx.read_immediate(value)?),
	"uninitialized raw pointer",
	self.path
	);

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Type validation mistreats layout errors #71353

Original issue

35 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Participants

Type validation mistreats layout errors #71353

Description

Original issue

Activity

RalfJung commented on Apr 20, 2020

jonas-schievink commented on Apr 20, 2020

rustbot commented on Apr 20, 2020

RalfJung commented on Apr 20, 2020

Michael-F-Bryan commented on Apr 20, 2020

senden9 commented on Apr 20, 2020

35 remaining items

LeSeulArtichaut commented on May 3, 2020

Mark-Simulacrum commented on May 3, 2020

LeSeulArtichaut commented on May 3, 2020

RalfJung commented on May 3, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Participants

Issue actions