-
Notifications
You must be signed in to change notification settings - Fork 36
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
high
interface soundness
#34
Comments
@xacrimon I received your Email about the soundness issue, but hadn't had time to reply yet. Since this issue exists here now, let's keep the conversation here. That way the same things won't be discussed in two different places 😄 @Monadic-Cat You're right the API has some soundness issues. We had them in the past as well (just noticed you also reported that one). The challenge here is that I don't use the high or medium level APIs myself, nor do I know how many others use them. Personally I really want to get rid of them, as maintaining the low-level API is hard enough already. Now the low-level API might have its own issues, but at least the code is largely Which brings me to the following: I'm not sure how to fix this in the high-level API. I also don't have the time for this in the coming weeks unfortunately. So if anybody can come up with any fixes that would be great. With that said, if this is going to require extensive changes I'd much rather mark the high and mid APIs as deprecated and remove them entirely in a new major version. |
To add to that: my rough long term idea would be to nuke the high/mid APIs, make "low" the only API, then gradually try to make the APIs safe where it makes sense. 100% safety probably never will be achieved due to how libffi works, but there are probably places where we can make improvements. |
I used to use |
@yorickpeterse Great! When we do land fixes, we should probably |
A quick search of GitHub shows these public usages of And these use |
@xacrimon I won't be yanking anything, because:
Given the risk factor being small, it simply isn't worth it. |
@yorickpeterse Fair, your call. That’s said yanking shouldn’t break existing builds. |
That's only the case for projects keeping their |
You could release a new semver-compatible release for all the to-be-yanked / unsound releases out there, with a |
As a first step, may I suggest documenting these soundness problems in a prominent place? |
Also, sorry about the soundness problems. Eek! |
From what I can tell, the ClosureMutN problem can be solved by making ClosureMutN::code_ptr() take The |
Actually, I’m a bit confused by
because currently the Closure…N types are Update: Is this about the |
Yep, impl Fn() + !Sync // parallel calls may cause UB
-> Closure0
--take a ref--> &Closure0
--.code_ptr()--> &FnPtr0
--ref can be sent across threads--> call it in parallel And similarly, for an |
I’m wondering whether the auto traits can be threaded through from the original Fn* to the FnPtrN as a phantom parameter.
No external synchronization afaik.
I believe that changing that |
Regarding threading the auto-traits, feel free to look at https://docs.rs/stackbox/latest/src/stackbox/dyn_traits/any.rs.html#31-40 for a not-so-far example; Once that's done, the auto-trait issue will be fixed, and indeed if |
That's all I'm aware of, but I don't have high confidence that that's all. |
So, I believe #40 fixes the mutability erasure problem. I think it should be merged, but I’d like a second opinion first. The auto trait problem is tougher. #42 makes FnPtrN Two possibilities:
Any thoughts? |
These are the soundness issues I'm aware of in the
high
interface:Send
andSync
)ClosureMutN
can be called by shared reference)There may be more that I'm not aware of, though the pattern seems to be that the
high
interface erases too much information to be able to effectively lean on the compiler checking things for us.I'd like to work on fixing these, though I'm having trouble forming a solid idea of how to fix the auto trait problem.
The text was updated successfully, but these errors were encountered: