Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)
Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)
Posted Nov 1, 2023 16:24 UTC (Wed) by Wol (subscriber, #4433)In reply to: Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack) by mb
Parent article: Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)
And, as others have said, this is the root of the problem. You are assuming the compiler is compiling some "perfect" program. Which, as we all know, is pretty much impossible.
The correct approach is to convert all undefined behaviour into the "crash" operator, at which point you can optimise the code to "if input is valid then call function else crash". You've optimised multiple "elseif" operators into just one.
Okay, that's not QUITE as efficient as optimising the test out completely and just assuming that undefined behaviour never happens. But it's far safer, and at very little cost.
That is where Rust scores - it doesn't assume the programmer is omniscient and can write code without undefined behaviour. It optimises it, and if it finds it outside an unsafe block it treats it as a coding error.
Cheers,
Wol
Posted Nov 1, 2023 21:14 UTC (Wed)
by khim (subscriber, #9252)
[Link] (6 responses)
Rust absolutely does assume that and I have shown quite a few examples where it does that. It just “assumes that programmer is omniscient” if said programmer uses that magical That's very big difference from what “we code for the harwdare” Sure. But that whole scheme to work for low-level system-programming style language it have to assume that at least some developers are omniscient. And they always avoid UBs. Only in normal, “safe” Rust detection of UBs is responsibility of the compiler and in Rust does give them Miri but that one is only helper in a fight with UBs: if it detects an UB in your code then it's almost certainly a bug and have to be fixed (there are very few false positives in Miri, but they do exist), the main tool is still omnisciency of developers with
Posted Nov 2, 2023 10:12 UTC (Thu)
by kleptog (subscriber, #1183)
[Link] (5 responses)
It a cultural thing though. If a programmer used unsafe in the examples you provided the patch would simply be rejected out of hand during code review. So the example is in that sense contrived: such code would never be merged into a real project, so why discuss it? There is no reason to use unsafe in normal situations. I would actually expect that kernel drivers written in Rust would be required to have zero uses of unsafe. Anywhere that it might be needed would be abstracted into a separate module that can be audited and shared.
So the programmer doesn't need to be omniscient, they just need to not use unsafe, which is totally feasible. None of the Rust programs I've ever written has needed unsafe.
PS. I'm kind of awe at the use of formatting in this thread. Are people typing all this HTML by hand?
Posted Nov 2, 2023 10:34 UTC (Thu)
by farnz (subscriber, #17727)
[Link]
Yes, I type all the HTML I use for formatting by hand; I've been using HTML for decades, so it's not challenging to do, including getting the various > and < type escapes right.
And it's important, I think, to call out that the unsafe keyword is a cultural enabler; on it's own, it does nothing to improve coding standards, but it means that as a reviewer, I can focus harder on the few places where unsafe is used, with a view to being confident that the safety guarantees are upheld. Doing this for the entire change is sufficiently hard that most reviewers won't bother.
Posted Nov 2, 2023 12:03 UTC (Thu)
by pizza (subscriber, #46)
[Link] (3 responses)
Uh, code review by whom, exactly?
Review by the your same corporate peers who are currently writing crappy C++?
Most code written will never escape outside the corporate firewall, which means the culture that will actually be applied is the same corporate malaise that produces the current awful C++ status quo.
Posted Nov 2, 2023 12:51 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (2 responses)
Yes, the same corporate peers who try to write great C++ but fail because of the difficulty in doing so.
The culture issue is that you only have a limited amount of time to do everything; without mechanical assistance, doing a good job is simply too hard. Because C++ makes it challenging to provide mechanical assistance that says (among other things) "this program is ill-formed (no diagnostic required)" or "this program executes UB (no diagnostic required", people take short-cuts; they assume that if they see enough tests, and if the -Wall -Wextra -Werror CI is green, then the program has no UB, but this is false.
A change of language (to Java, to Rust, to Python) means that those shortcuts they're taking now work; if CI is green, the program really does have fully defined behaviour.
Posted Nov 2, 2023 22:42 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
We had deadlocks in a few tests in the test suite. Fine, rerun the CI job when it happens…usually OK. When I finally got around to tracking it down, it turns out that it is 100% in the test suite itself (so doesn't affect the deployment; I kind of knew this already and it was why it was on the backburner for so long):
- we have one thread act as a "hosting service" that takes the role of a forge dealing with git hook calls triggering webhook events and such;
In the deadlock, the "service" side was blocked waiting on write access to the data to handle an event. The "client" was blocked on the full channel trying to send a new event. However, it did so while holding a read-only lock on that shared data structure. Sure, an unbuffered channel would have worked too, but that seemed "hacky" to me. Instead, the fix is to only send events on the channel when the read lock is *not* held. That is fixed here:
https://gitlab.kitware.com/utils/ghostflow-director/-/com...
C++ would have had the same fix for this problem. Fine, the test suite is happy.
However, I knew that over time, guaranteeing that the read lock was not held anywhere in the call stack when sending on the channel was a hard problem. But Rust enforces "mutable XOR shared" access, so the "this will never happen again" fix is possible:
https://gitlab.kitware.com/utils/ghostflow-director/-/com...
Now, access to a read lock is mediated through a `&mut` reference to a struct containing the channel and the data. Sending on the channel *also* requires a `&mut` reference. The compiler will therefore enforce that if the channel is accessed, the data lock is not held (as to get it, you need to hold a `&mut` reference to the structure).
This is the kind of stuff one can construct with Rust's rules: not only is the bug fixed, but *it can never happen again*.
Posted Nov 3, 2023 11:27 UTC (Fri)
by farnz (subscriber, #17727)
[Link]
That's the sort of thing I was thinking of with "CI is green" checks; you've been able to take a hard problem, and convert it to "if CI goes green, then the problem doesn't exist". Because developers use "CI is green" as a short-cut for "the code works as intended", doing this means that taking that short-cut is OK.
> That is where Rust scores - it doesn't assume the programmer is omniscient and can write code without undefined behaviour.
Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)
unsafe keyword.O_PONIES lovers demand from C++ compilers.unsafe Rust that's responsibility of the developer.unsafe superpowers.Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)
Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)
Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)
Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)
Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)
- one thread acts as the "client" for the tests to emulate performing actions;
- there is a shared RwLock'd data block so that the client can get access read-only data access as needed (avoiding the need for synchronous channel communications on the client side);
- there is a sized channel to send requests to the service (in lieu of HTTP in normal usage).
Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)