diff options
| author | bors <bors@rust-lang.org> | 2024-10-08 01:56:58 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2024-10-08 01:56:58 +0000 |
| commit | b8495e5dd22fa16fc86d6871b34c7891a6a3ee27 (patch) | |
| tree | dda908c079378a8d6a2e51c3db81d040eaa824d3 /tests/coverage/drop_trait.coverage | |
| parent | 3ae715c8c63f9aeac47cbf7d8d9dadb3fa32c638 (diff) | |
| parent | 8d562f6cc57b40e3c184f0eb72cb5de845d2e046 (diff) | |
| download | rust-b8495e5dd22fa16fc86d6871b34c7891a6a3ee27.tar.gz rust-b8495e5dd22fa16fc86d6871b34c7891a6a3ee27.zip | |
Auto merge of #130251 - saethlin:ptr-offset-preconditions, r=Amanieu
Add precondition checks to ptr::offset, ptr::add, ptr::sub All of `offset`, `add`, and `sub` (currently) have the trivial preconditions that the offset in bytes must be <= isize::MAX, and the computation of the new address must not wrap. This adds precondition checks for these, and like in slice indexing, we use intrinsics directly to implement unsafe APIs that have explicit checks, because we get a clearer error message that mentions the misused API not an implementation detail. Experimentation indicates these checks have 1-2% compile time overhead, due primarily to adding the checks for `add`. A crater run (https://github.com/rust-lang/rust/pull/130251#issuecomment-2395824565) indicates some people currently have buggy calls to `ptr::offset` that apply a negative offset to a null pointer, but the crater run does not hit the `ptr::add` or `ptr::sub` checks, which seems like an argument for cfg'ing out those checks on account of their overhead.
Diffstat (limited to 'tests/coverage/drop_trait.coverage')
0 files changed, 0 insertions, 0 deletions
