intptrcast: Never allocate two objects directly adjecent #1930
Conversation
|
Thanks for the MR! I am not very happy about this work-around, since it is just that -- it doesn't actually solve the problem, it just makes it less likely to occur in practice. But that is probably still better than the status quo. I opened rust-lang/unsafe-code-guidelines#313 to track the fundamental problem that causes this. |
tavianator
force-pushed
the
avoid-adjacent-allocations
branch
from
b1fe9a8
to
d432e5f
Compare
When two objects directly follow each other in memory, what is the provenance of an integer cast to a pointer that points directly between them? For a zero-size region, it could point into the end of the first object, or the start of the second. We can avoid answering this difficult question by simply never allocating two objects directly beside each other. This fixes some of the false positives from rust-lang#1866.
tavianator
force-pushed
the
avoid-adjacent-allocations
branch
from
d432e5f
to
b0a4633
Compare
Agreed, although depending on what “the problem“ is, I expect it's either very difficult or impossible to solve :). I'm not sure there's a consistent semantics at all for a language with both pointer provenance and pointer<->integer casts. Though I haven't been following the C provenance working group stuff. |
I sure hope there is, because otherwise I have to either remove int-to-ptr casts from Rust or live with the fact that Rust is internally inconsistent and fundamentally impossible to get right. ;) But if there is a counterexample that demonstrates that no such semantics can exist, that would sure be very interesting. |
|
@bors r+ Thanks again for the fix. :) |
|
📌 Commit 6a98c64 has been approved by |
|
☀️ Test successful - checks-actions |
When two objects directly follow each other in memory, what is the
provenance of an integer cast to a pointer that points directly between
them? For a zero-size region, it could point into the end of the first
object, or the start of the second.
We can avoid answering this difficult question by simply never
allocating two objects directly beside each other. This fixes some of
the false positives from #1866.