Deny unsafe_op_in_unsafe_fn by default
#801
Conversation
tgross35
force-pushed
the
edition-2024-prep
branch
7 times, most recently
from
8dd54af to
4df5a5b
Compare
Edition 2024 requires that we avoid this. There is a lot of code that will need to be adjusted, so start the process here with a warning that will show up in CI.
tgross35
force-pushed
the
edition-2024-prep
branch
from
4df5a5b to
699c1a2
Compare
| // TODO | ||
| unsafe { | ||
| dst = dst.offset(1); | ||
| src = src.offset(1); | ||
| } |
There was a problem hiding this comment.
@RalfJung is using offset to create a pointer one past the end of the allocation allowed? This caught my eye when adding safety comments; the docs say "the entire memory range between self and the result must be in bounds of that allocated object" and Miri doesn't complain, but I had been thinking that it was at least indeterminate (and now I can't find the issue).
There was a problem hiding this comment.
If an allocation has size 4, and a ptr starts at offset 0 and you add 4 to it, then the memory range between the old and new pointer has size 4. Clearly that is entirely inbounds. Not sure what you mean by "indeterminate" here -- we don't use that word in Rust, and in C it is used to refer to values/representations, not operations, so I can't make sense of it here.
I think "one past the end" is bad terminology, since the pointer is not past the end, it is at the end -- it points after the last element.
There was a problem hiding this comment.
Yeah that's straightforward enough. I must be misremembering; I thought there was an open issue somewhere related to differences between Rust and C here regarding creating a pointer past (or at) the end of an allocation and how that related to memcpy, but maybe this was only about wrapping at the end of the address space.
Not sure what you mean by "indeterminate" here -- we don't use that word in Rust
Indeterminate only because it had not yet been decided, not technical terminology.
There was a problem hiding this comment.
I'm probably thinking of rust-lang/unsafe-code-guidelines#465 and related discussion, which has been decided and I'm just a year out of date :) So as I understand it, a Rust program can never access the last byte of the address space and that effectively means our memcpy doesn't have to worry about it - with the result that these offset calculations will never wrap.
|
Yeah the last byte of the addr space does not have a pointer "after" it, making it special. At least clang has the same limitation as Rust here, I do not know about standard C.
|
|
Finally found what I was thinking of related to memcpy #713 and its context around #t-compiler > Hello World on sparc-unknown-none-elf crashes @ 💬. |
Edition 2024 requires that we avoid this. There is a lot of code that will need to be adjusted, so start the process here.