-
-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Unsoundness without forget #30
Comments
👍 |
Why closed? Is there an issue with the demonstration of unsoundness without using |
It was closed because it is known, and not a problem. This project is art. At some point it change. Feel free to open a PR. |
Issues like this kill any motivation to improve things. Not helpful. Open a PR instead. |
Pointing possible UB in a library described as "misuse resistant" is helpful... Seriously, we don't want another actix like debacle, but we also don't want libraries with known problems that can cause UB in production. And I say this because it's incredible code and we as a community have evolved a lot in the async world, but it's only with issues like this we can actually make the ecosystem mature. It's new stuff and we are still figuring things out, but pointing possible problems is a great start. Sure maybe it can be kept open and marked as wont-fix, or waiting-for-pr. But why close it like it's solved? It's important to have that documented, specially because if UB happens it won't point directly to the docs that explain it. The dev will have a better time looking for open issues. And if it proves to be a problem in production the community might move together to fix. Closing won't help. I'm not saying you should fix it, just leave it there for posteriority, those issues always prove to be useful. |
So you would accept a PR that marks all methods returning a |
At the risk of speaking on the author's behalf, it sounds like they are asking for help to fix this. Theoretically, keeping an issue tagged as "open" might inspire someone to jump in and help, but that isn't necessarily the case. Keep in mind that the subset of people who understand and could fix (not me!), are likely to be aware of this anyway, so closing it doesn't make it disappear. It's important to note that the mental toll of having an "open" UB issue is worth considering, especially if the author has to see it all the time. This is especially true in the current state of the world. Perhaps a more helpful route would be a PR that updates the documentation appropriately, to reference this issue, such that it is visible to interested parties, despite being "closed". |
This ain't actix. Look at the dependent crates. All but 1 are mine, and I aggressively hunt leaks in my code because that is table stakes for a real program. I don't accept this drama. If you see yourself using this crate or an improved version, I'm interested in speaking with you. Otherwise, go raise your pitchforks elsewhere :) |
I came across the following note in https://docs.rs/rio/0.9.3/rio/struct.Completion.html, which I found surprising and possibly disingenuous:
In trying to understand the backstory of your position on this, I found this sequence of tweets from which I think I see the misunderstanding on your part:
In case it helps see why these tweets are wrong, I wrote up some example code that demonstrates stack corruption (or heap corruption / use after free / however you want it) without any involvement of
forget
.The same misunderstanding in rio was called out recently by someone else in https://www.reddit.com/r/rust/comments/hk8lab/ringbahn_ii_the_central_state_machine/fwt0xmt/.
Hopefully the example code will help identify a path to making a sound API for rio; otherwise it would be good to clarify the documentation to make it clear that the safety proposition is "hope that nothing else in your code interacts poorly with rio's assumptions about Rust semantics", rather than anything specific about
forget
.The text was updated successfully, but these errors were encountered: