Miri: relax fn ptr check #94270
Merged
Miri: relax fn ptr check #94270
Conversation
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
rustbot
added
the
T-compiler
|
Some changes occured to the CTFE / Miri engine cc @rust-lang/miri |
rust-highfive
added
the
S-waiting-on-review
RalfJung
force-pushed
the
fn-ptrs
branch
2 times, most recently
from
9065caf
to
346b8fa
Compare
oli-obk
reviewed
Feb 23, 2022
| let _fn = try_validation!( | ||
| self.ecx.memory.get_fn(ptr), | ||
| self.path, | ||
| err_ub!(DanglingIntPointer(..)) | |
There was a problem hiding this comment.
Do we have tests for these two errors? At least the test you edited doesn't have them, though it tests similar things for regular references
There was a problem hiding this comment.
Fair point, this is a good opportunity to increase our test coverage.
|
@bors r+ rollup |
|
📌 Commit 182d335 has been approved by |
bors
added
S-waiting-on-bors
|
You are too quick, I just wanted to write that I added more tests... |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 24, 2022
…askrgr Rollup of 9 pull requests Successful merges: - rust-lang#89887 (Change `char` type in debuginfo to DW_ATE_UTF) - rust-lang#94267 (Remove unused ordering derivations and bounds for `SimplifiedTypeGen`) - rust-lang#94270 (Miri: relax fn ptr check) - rust-lang#94273 (add matching doc to errorkind) - rust-lang#94283 (remove feature gate in control_flow examples) - rust-lang#94288 (Cleanup a few Decoder methods) - rust-lang#94292 (riscv32imc_esp_espidf: set max_atomic_width to 64) - rust-lang#94296 (:arrow_up: rust-analyzer) - rust-lang#94300 (Fix a typo in documentation of `array::IntoIter::new_unchecked`) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Feb 25, 2022
Miri fn ptr check: don't use conservative null check In rust-lang#94270 I used the wrong NULL check for function pointers: `memory.ptr_may_be_null` is conservative even on machines that support ptr-to-int casts, leading to false errors in Miri. This fixes that problem, and also replaces that foot-fun of a method with `scalar_may_be_null` which is never unnecessarily conservative. r? `@oli-obk`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As discussed in rust-lang/unsafe-code-guidelines#72 (comment), the function pointer check done by Miri is currently overeager: contrary to our usual principle of only checking rather uncontroversial validity invariants, we actually check that the pointer points to a real function.
So, this relaxes the check to what the validity invariant probably will be (and what the reference already says it is): the function pointer must be non-null, and that's it.
The check that CTFE does on the final value of a constant is unchanged -- CTFE recurses through references, so it makes some sense to also recurse through function pointers. We might still want to relax this in the future, but that would be a separate change.
r? @oli-obk