-
Notifications
You must be signed in to change notification settings - Fork 353
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can/should miri ensure that the addresses of consts/vtables/... are unstable? #1955
Comments
The code that was found was https://github.com/LightningCreations/lccc/blob/6377fff74e4de2b98eac1ea78db60baf87d75cbb/xlang/xlang_abi/src/string.rs#L380 (in my project, but not my code directly, credits in the comment). I'd note that it seems like a potentially huge footgun that rust does not guarantee this, especially since, coming from C++, I wouldn't expect |
This seems related to #131.
This is somewhat documented at https://github.com/rust-lang/const-eval/blob/master/const.md, but I agree it is subtle. The upshot is that if you care about address identity, you have to use |
Sometimes you can't do that, though. My code was a macro intended to be used for intializating values of type |
Are you saying you want the language changed to accommodate your implementation? I'm very confused |
If the const is generic it is even impossible to guarantee address identity as two crates may instantiate it with the same address. Also note that even functions and vtables don't have a guaranteed identity. Vtables are always duplicated per cgu and functions may be duplicated and we tell LLVM that we don't care about address identity for functions. |
For the record, this is how we handle having a constant of "significant address" in But we can't really guarantee much more without limiting platform support. That is, being able to guarantee linker-based deduplication 100% of the time (e.g. by encoding the data in the symbol, though we'd have to use hashes for really large ones, and then having the linker deduplicate by symbol) is isomorphic to This is also, FWIW, the same reason we don't offer anything resembling generic/associated |
Right, so this issue is basically the opposite -- in Miri, each const and vtable has a unique address, and it is non-trivial to change that. ;) But we probably do want to change it to get more test coverage. |
Oh right, I did misunderstand the original issue description as saying the opposite, and just assumed a significant refactor had already happened. Given we don't want to guarantee either (or to sound less sill: make every use of a constant reference have non-deterministic |
Yeah, something like that. Though the nondet needs to happen when the fn check<T>(x: *const T, y: *const T) -> bool {
(x == y) == (x == y)
} |
I agree, I was just struggling to describe it precisely enough (that's why I mentioned |
In the original testing, whether you get a unique address or not depends on what level you evaluate the const to. In the case of an |
We previously assumed that &'static str would always have the same address, but with miri it seems like this address is not actually stable (see rust-lang/miri#1955). So refactor the tests to let it use the StringInterner instead of constructing InternedString by itself.
FWIW, right now Miri makes the address of #1955 will make vtables and everything else non-unique for each time they get turned into a pointer, so consts are the only things where we still have some kind of uniqueness. (We certainly don't guarantee that kind of per-fn-invocation uniqueness today though, this is just a Miri implementation choice.) |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
Here's the UCG issue to discuss what we should guarantee if we want to guarantee more than nothing: rust-lang/unsafe-code-guidelines#522. EDIT: Ah, you just found it. :) |
While rust-lang/rust#128742 does overall make things less stable, it also makes it so that when a function pointer is created in CTFE that now always produces the same result, so those function pointers are now actually more stable. Creating a full new allocation for each CTFE-created function pointer does seem excessive though (that's what we did before that PR) and using an RNG is tricky given the compiler's determinism requirements, so... not sure what the best solution here is. |
In the community Discord, someone recently found a bug in their code (or idea?) because the address of a const value wasn't stable in miri, but was stable in normal execution.
As demonstration, someone posted this example:
Which on the playground currently prints
But then OP responded with this example:
Which on the playground currently prints
This seems less-than-awesome. Is there something that miri can do to make sure that addresses of consts aren't accidentally stable across instantiations? Or at least, are very unlikely to be stable?
The text was updated successfully, but these errors were encountered: