14 ms·

Interesting - thanks for sharing that. Though that article does make things a little clearer, I get the impression we should really have three circles on a venn

Interesting - thanks for sharing that. Though that article does make things a little clearer, I get the impression we should really have three circles on a venn diagram - essentially, I'm decoupling the concepts of "unsound" and "bug": - Bug - i.e. some unintended action of a piece of code - unsound - i.e. code that can be used (or abused) to produce unsafe effects - unsafe-bleed - i.e. code that cannot be proven to be safe at compile time, or even potentially code that can be proven to be unsound, that a third-party developer could legitimately use without knowing it was unsafe/unsound. The question I'm curious about is what the proposed PRs fixed. It's clear they didn't fix a bug; the API used was part of the undocumented internals (afaik), and all internal uses of the code were reportedly clean. It maybe "fixed" an unsoundness, future developers of the project may indeed have misused this code and received undefined behaviour as a result (again, I don't know how common or uncommon the particular misuse would be in the rust community) I don't know whether this fixed an unsafe-bleed though; whether a third party has access to these objects and has the ability to combine them in such a way as to produced undefined behaviour. My question to you is: is this a Bug, such that the code did not perform as expected; Is there a bleed of unsafety here, where the permissions model of rust allows access outside the crate to these implementation details; or is it just unsoundness - and if so, could the unsoundness have been mitigated some other (more performant) way?

Rusky 7y ago
In the most recent issue, there was in fact demonstrated "unsafe-bleed," in the sense that client code could hit undefined behavior by using public safe APIs a particular way.
burntsushi 7y ago
I don't have the time or desire to answer that question. That would require a level of scrutiny into specific PRs and details that I don't think is productive to go into. I think my clarification stands on its own. Gratuitous use of `unsafe` is bad on its own, and unsound `unsafe` use is also bad on its own. They are two different categories of problems. Both were present in actix. These weren't the only issues, but others have addressed those. My only point was to clarify that the issue wasn't just frequency. Soundness was also an issue. Whether this only impacts actix developers or whether it impacts users of actix is, I grant, an important question in order to asses just how much you should freak out about any particular soundness problem. (As dtolnay points out, sometimes you don't need to freak out at all. So my statement includes "zero amount." But I am intentionally conveying a bias here: some level of freak out is probably appropriate in a high profile ecosystem level project for Rust specifically. IMO.)

Rusky 7y ago

In the most recent issue, there was in fact demonstrated "unsafe-bleed," in the sense that client code could hit undefined behavior by using public safe APIs a particular way.

burntsushi 7y ago

I don't have the time or desire to answer that question. That would require a level of scrutiny into specific PRs and details that I don't think is productive to go into. I think my clarification stands on its own. Gratuitous use of `unsafe` is bad on its own, and unsound `unsafe` use is also bad on its own. They are two different categories of problems. Both were present in actix. These weren't the only issues, but others have addressed those. My only point was to clarify that the issue wasn't just frequency. Soundness was also an issue. Whether this only impacts actix developers or whether it impacts users of actix is, I grant, an important question in order to asses just how much you should freak out about any particular soundness problem. (As dtolnay points out, sometimes you don't need to freak out at all. So my statement includes "zero amount." But I am intentionally conveying a bias here: some level of freak out is probably appropriate in a high profile ecosystem level project for Rust specifically. IMO.)