-
Notifications
You must be signed in to change notification settings - Fork 12.4k
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
[strict provenance] Rationalize "Oxford Casts" #95489
Comments
Oh also, it might be useful/important to make it easier to talk about "some" function pointer. That came up a lot in places with oxford casts. The problematic code above is already flailing at the classic Tuple Problem: rust/library/core/src/ptr/mod.rs Lines 1746 to 1758 in bb5c437
Too tired to dig up the links but there is also:
I sketched out an OpaqueFnPtr type type in sptr but without lang support it has to do the transmute_copy nightmare I describe above so it's unclear if it's at all useful. |
Oh wait nice, I forgot I actually originally "fixed" all these cases and then got skittish about it, but left the "revert" as a separate commit precisely so it would be easier to see all the places where we do "interesting" stuff with function pointers: |
Arguably it is a bug that rustc generates fn ptrs and raw ptrs into different address spaces but then fails to emit addrspacecasts between them when lowering casts. This is really not something that library code should have to work around. |
I think I mentioned this on Twitter, but just as a note, the specific libcore cast mentioned just gets converted back to a |
…=Mark-Simulacrum Be a little nicer with casts when formatting `fn` pointers This removes a `fn(...) -> ...` -> `usize` -> `*const ()` -> `usize` cast. cc rust-lang#95489.
…=Mark-Simulacrum Be a little nicer with casts when formatting `fn` pointers This removes a `fn(...) -> ...` -> `usize` -> `*const ()` -> `usize` cast. cc rust-lang#95489.
This issue is part of the Strict Provenance Experiment - #95228
Oxford Casts are those that fly in the face of Harvard Architectures, and let you convert between data pointers and function pointers. In my current understanding, this affects both AVR and WASM.
For WASM, function pointers are actually indices into a ~vtable somewhere. This seems to mostly work fine and it's just a matter of "ask bad questions, get bad answers"
For AVR it causes Actual Compiler Problems that the stdlib seems to be actively routing around:
rust/library/core/src/ptr/mod.rs
Lines 1390 to 1395 in 9280445
I do not know what "resolving" this looks like. It could involve any of:
I can't really help any more than this, because this is all outside my areas of expertese/motivation.
The text was updated successfully, but these errors were encountered: