zlacker

[return to "“Rust is safe” is not some kind of absolute guarantee of code safety"]
1. a_hume+h4[view] [source] 2022-10-02 14:51:10
>>rvz+(OP)
I know next to nothing about kernel programming, but I'm not sure here what Linus' objection to the comment he is responding to here is.

The comment seemed to be making reference to rust's safety guarantees about undefined behaviour like use after free.

Linus' seems to have a completely different definition of "safey" that conflates allocation failures, indexing out of bounds, and division by zero with memory safety. Rust makes no claims about those problems, and the comment clearly refers to undefined behaviour. Obviously, those other problems are real problems, but just not ones that Rust claims to solve.

Edit: Reading the chain further along, it increasingly feels like Linus is aruging against a strawman.

◧◩
2. arinle+u9[view] [source] 2022-10-02 15:21:47
>>a_hume+h4
> I know next to nothing about kernel programming, but I'm not sure here what Linus' objection to the comment he is responding to here is.

You should read the email thread, as Linhas explains in clear terms.

Take for instance Linus's insightful followup post:

https://lkml.org/lkml/2022/9/19/1250

◧◩◪
3. ChrisS+ja[view] [source] 2022-10-02 15:26:30
>>arinle+u9
What is better: continuing to "limp along" in some unknown corrupted state (aka undefined behaviour) or in a well defined (albeit invalid) state?
◧◩◪◨
4. throw8+of[view] [source] 2022-10-02 15:55:13
>>ChrisS+ja
Had the same topic often on MCUs: limp along to hopefully get the error out somehow, otherwise it won't be noticed if not with JTAG debugger attached (default in field).

So I can understand where Linus comes from.

◧◩◪◨⬒
5. gmueck+Ht[view] [source] 2022-10-02 17:10:32
>>throw8+of
Yes. You could still hard reset after the error is reported if you wanted to. And if system availability matters, a hardware watchdog would handle the case where the error handling doesn't finish.
[go to top]