-
Notifications
You must be signed in to change notification settings - Fork 323
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.
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: