forked from rust-lang/rust
-
Notifications
You must be signed in to change notification settings - Fork 7
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Auto merge of rust-lang#102513 - RalfJung:no-more-unaligned-reference…
…, r=cjgillot,scottmcm make unaligned_reference a hard error The `unaligned_references` lint has been warn-by-default since Rust 1.53 (rust-lang#82525) and deny-by-default with mention in cargo future-incompat reports since Rust 1.62 (rust-lang#95372). Current nightly will become Rust 1.66, so (unless major surprises show up with crater) I think it is time we make this a hard error, and close this old soundness gap in the language. EDIT: Turns out this will only land for Rust 1.67, so there is another 6 weeks of time here for crates to adjust. Fixes rust-lang#82523.
- Loading branch information
Showing
27 changed files
with
170 additions
and
686 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,64 @@ | ||
An unaligned references to a field of a [packed] struct got created. | ||
|
||
Erroneous code example: | ||
|
||
```compile_fail,E0793 | ||
#[repr(packed)] | ||
pub struct Foo { | ||
field1: u64, | ||
field2: u8, | ||
} | ||
unsafe { | ||
let foo = Foo { field1: 0, field2: 0 }; | ||
// Accessing the field directly is fine. | ||
let val = foo.field1; | ||
// A reference to a packed field causes a error. | ||
let val = &foo.field1; // ERROR | ||
// An implicit `&` is added in format strings, causing the same error. | ||
println!("{}", foo.field1); // ERROR | ||
} | ||
``` | ||
|
||
Creating a reference to an insufficiently aligned packed field is | ||
[undefined behavior] and therefore disallowed. Using an `unsafe` block does not | ||
change anything about this. Instead, the code should do a copy of the data in | ||
the packed field or use raw pointers and unaligned accesses. | ||
|
||
``` | ||
#[repr(packed)] | ||
pub struct Foo { | ||
field1: u64, | ||
field2: u8, | ||
} | ||
unsafe { | ||
let foo = Foo { field1: 0, field2: 0 }; | ||
// Instead of a reference, we can create a raw pointer... | ||
let ptr = std::ptr::addr_of!(foo.field1); | ||
// ... and then (crucially!) access it in an explicitly unaligned way. | ||
let val = unsafe { ptr.read_unaligned() }; | ||
// This would *NOT* be correct: | ||
// let val = unsafe { *ptr }; // Undefined Behavior due to unaligned load! | ||
// For formatting, we can create a copy to avoid the direct reference. | ||
let copy = foo.field1; | ||
println!("{}", copy); | ||
// Creating a copy can be written in a single line with curly braces. | ||
// (This is equivalent to the two lines above.) | ||
println!("{}", { foo.field1 }); | ||
} | ||
``` | ||
|
||
### Additional information | ||
|
||
Note that this error is specifically about *references* to packed fields. | ||
Direct by-value access of those fields is fine, since then the compiler has | ||
enough information to generate the correct kind of access. | ||
|
||
See [issue #82523] for more information. | ||
|
||
[packed]: https://doc.rust-lang.org/reference/type-layout.html#the-alignment-modifiers | ||
[undefined behavior]: https://doc.rust-lang.org/reference/behavior-considered-undefined.html | ||
[issue #82523]: https://github.com/rust-lang/rust/issues/82523 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
13 changes: 10 additions & 3 deletions
13
src/tools/miri/tests/fail/unaligned_pointers/reference_to_packed.rs
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,19 +1,26 @@ | ||
// This should fail even without validation/SB | ||
//@compile-flags: -Zmiri-disable-validation -Zmiri-disable-stacked-borrows | ||
|
||
#![allow(dead_code, unused_variables, unaligned_references)] | ||
#![allow(dead_code, unused_variables)] | ||
|
||
use std::{ptr, mem}; | ||
|
||
#[repr(packed)] | ||
struct Foo { | ||
x: i32, | ||
y: i32, | ||
} | ||
|
||
unsafe fn raw_to_ref<'a, T>(x: *const T) -> &'a T { | ||
mem::transmute(x) | ||
} | ||
|
||
fn main() { | ||
// Try many times as this might work by chance. | ||
for _ in 0..20 { | ||
let foo = Foo { x: 42, y: 99 }; | ||
let p = &foo.x; | ||
let i = *p; //~ERROR: alignment 4 is required | ||
// There seem to be implicit reborrows, which make the error already appear here | ||
let p: &i32 = unsafe { raw_to_ref(ptr::addr_of!(foo.x)) }; //~ERROR: alignment 4 is required | ||
let i = *p; | ||
} | ||
} |
4 changes: 2 additions & 2 deletions
4
src/tools/miri/tests/fail/unaligned_pointers/reference_to_packed.stderr
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.