Consider changing #![deny(unsafe_code)] to #![forbid(unsafe_code)]. The difference is that deny can be overridden by a local #[allow(unsafe_code)], while forbid cannot: https://doc.rust-lang.org/rustc/lints/levels.html
andersk
u/andersk
Feed options
Hot
New
Top
View
Card
Compact
Evidently this patch was dropped from 6.14.8 final: “drop drm patch after it caused issues in testing.”
Looks like you’re aware already, but this one is https://gitlab.freedesktop.org/mesa/mesa/-/issues/12528 (fixed in 6.15-rc7 and 6.14.8-rc1).
There is no “the Condorcet method”, but rather many different Condorcet methods, i.e. election methods that elect the Condorcet winner if it exists (https://en.wikipedia.org/wiki/Condorcet_method).
Of these, it looks like you’ve chosen to implement a variant of Copeland’s method (https://en.wikipedia.org/wiki/Copeland%27s_method) with each pairwise win/tie/loss counted as 1/0/0 rather than 1/½/0. Consider documenting your choice and replacing vague terms like “Condorcet-style”.
Result::flatten converts Result<Result<T, E>, E> to Result<T, E>, but it’s nightly-only. The stable solution is .and_then(|r| r). (If E1 and E2 are different, convert one or both with .map_err.)
Note that “and then the inner one must be handled without passing it up” is misleading, as one can use ??.
You have not explained any gaps in the memory safety of safe Rust. You’ve pointed out that unsafe exists (yes), and you’ve pointed out that code in any language can still have bugs other than memory safety bugs (yes), but none of that has anything to do with the claim that safe Rust is memory-safe.
I understand how signals work, and I never suggested they are caught by the language runtime. Please read what I’m saying. In C++ and multithreaded Go, you can have undefined behavior that might be caught by the kernel and stopped with SIGSEGV if you are lucky, or might result in unrelated memory corruption and security vulnerabilities if you are unlucky. That’s guaranteed not to happen in a memory-safe language, such as safe Rust (and to be crystal clear—yes, this includes safe Rust programs built on top of the standard library including its internal unsafe blocks).
There is a huge difference between a language where memory unsafety can only happen in a small number of well-delimited, well-verified sections that have already been written for you and wrapped in a safe API that cannot be misused, and a language where memory unsafety could happen anywhere at all with no warning lights. That is the difference between a memory-safe language, and a memory-unsafe language in which careful enough programmers might manage to write some memory-safe programs.
We’re still not talking about preventing all bugs or all race conditions, as I’ve explained, but I’ll add that the consequence of a memory safety bug is arbitrary undefined behavior. SIGSEGV is actually the best case scenario since it means the poisoned execution was caught and halted, before it could cause more serious damage like arbitrary code execution and privilege escalation. Whereas the possible consequences of bugs in a safe language, though they might be similarly severe in a handful of application-specific scenarios, are much more predictable, containable, and traceable: a buggy threaded image parser might produce the wrong image or maybe abort the program but won’t scribble over unrelated memory and give shell access to a network attacker.
