4 ms·

Correct me if I'm wrong, but this comment is atleast partially incorrect right? > Since it was in an unsafe block, the error for sure was way easier to find wi

Correct me if I'm wrong, but this comment is atleast partially incorrect right? > Since it was in an unsafe block, the error for sure was way easier to find within the codebase than in C. Everything that's not unsafe can be ruled out as a reason for race conditions and the usual memory handling mistakes - that's already a huge win. The benefit of Rust is you can isolate the possible code that causes an XYZ to an unsafe block*. But that doesn't necessarily mean the error shown is directly related to the unsafe block. Like C++, triggering undefined behavior can in theory cause the program to do anything, including fail spectacularly within seemingly unrelated safe code. * Excluding cases where safe things are actually possibly unsafe (like some incorrectly marked FFI)

malcolmgreaves 10mo ago
The point at which you _could_ start to have undefined behavior is within an `unsafe` block or function. So even if the "failure" occurred in some "safe" part of the code, the conditions to make that failure would start in the unsafe code. When debugging, we care about where the assumptions we had were violated. Not where we observe a bad effect of these violated assumptions. I think you get here yourself when you say: > triggering undefined behavior can in theory cause the program to do anything, including fail spectacularly within seemingly unrelated safe code The bug isn't where it failed spectacularly. It's where the C++ code triggered undefined behavior. Put another way: if the undefined behavior _didn't_ cause a crash / corrupted data, the bug _still_ exists. We just haven't observed any bad effects from it.
landr0id 10mo ago
From my experience UB in Rust can manifest a bit differently than in C or C++, but still generally has enough smoke in the right area. I believe their point was that they only needed to audit only the unsafe blocks to find the actual root cause of the bug once they had an idea of the problematic area.
lousken 10mo ago
Why do they allow unsafe parts in linux kernel in the first place? Why rewriting C code into unsafe rust?
- tialaramex 10mo ago
  Rust is very nice for encapsulation. C isn't great at that work, and of course it can't express the idea that whatever we've encapsulated is now safe to use this way, in C everything looks equally safe/ unsafe.
  - informa23 10mo ago
    [flagged]
    - MyOutfitIsVague 10mo ago
      It's worth noting that "aliasing" in Rust and C typically mean completely unrelated things. Strict aliasing in C roughly means that if you initialize memory as a particular type, you can only access it as that type or one of a list of aliasable types look like char. Rust has no such restriction, and has no concept of strict aliasing like this. In Rust, "type aliasing" is allowed, so long as you respect size, alignment, and representability rules. Aliasing safety in Rust roughly means that you can not have an exclusive reference to an object if any other reference is active for that reference (reality is a little bit more involved than that, but not a lot). C has no such rule. It's very unfortunate that such similar names were given to these different concepts.
      - tialaramex 10mo ago
        No. Aliasing is a single idea, an alias is another name for the same thing. The concept translates well from its usual English meaning. The C "strict aliasing" rule is that with important exceptions the name for a thing of type T cannot also be an alias to a thing of type S, and char is an important exception. Linux deliberately switches off this rule. Rust's rule is that there mustn't be mutable aliases. We will see why that's important in a moment. Aliasing is an impediment to compiler optimisation. If you've been watching Matt's "Advent of Compiler Optimisation" videos (or reading the accompanying text) it's been covered a little bit in that, Matt uses C and C++ in those videos, so if you're scared of Rust you needn't fear that in the AoCO But why mutation? Well, the optimisations concern modification. The optimiser does its job by rewriting what you asked for as something (possibly not something you could have expressed at all in your chosen language) that has the same effect but is faster or smaller. Rewrites which avoid "spilling" a register (writing its value to memory) often improve both size and speed of the software, but if there is aliasing then spilling will be essential because the other aliases are referring to the same memory. If there's no modification it doesn't matter, copies are all identical anyway.
tialaramex 10mo ago
I guess the problem here is that you and the writer have different understandings of what "the error" means. The author is thinking about "the error" as some source code that's incorrect. "Your error was not bringing gloves and a hat to the snowball fight" but you're thinking "the error" is some diagnostic result that shows there was a problem. "My error is that I'm covered in freezing snow". Does that help?
informa23 10mo ago
[flagged]

malcolmgreaves 10mo ago

The point at which you _could_ start to have undefined behavior is within an `unsafe` block or function. So even if the "failure" occurred in some "safe" part of the code, the conditions to make that failure would start in the unsafe code. When debugging, we care about where the assumptions we had were violated. Not where we observe a bad effect of these violated assumptions. I think you get here yourself when you say: > triggering undefined behavior can in theory cause the program to do anything, including fail spectacularly within seemingly unrelated safe code The bug isn't where it failed spectacularly. It's where the C++ code triggered undefined behavior. Put another way: if the undefined behavior _didn't_ cause a crash / corrupted data, the bug _still_ exists. We just haven't observed any bad effects from it.

landr0id 10mo ago

From my experience UB in Rust can manifest a bit differently than in C or C++, but still generally has enough smoke in the right area. I believe their point was that they only needed to audit only the unsafe blocks to find the actual root cause of the bug once they had an idea of the problematic area.

lousken 10mo ago

Why do they allow unsafe parts in linux kernel in the first place? Why rewriting C code into unsafe rust?

tialaramex 10mo ago
Rust is very nice for encapsulation. C isn't great at that work, and of course it can't express the idea that whatever we've encapsulated is now safe to use this way, in C everything looks equally safe/ unsafe.
- informa23 10mo ago
  [flagged]
  - MyOutfitIsVague 10mo ago
    It's worth noting that "aliasing" in Rust and C typically mean completely unrelated things. Strict aliasing in C roughly means that if you initialize memory as a particular type, you can only access it as that type or one of a list of aliasable types look like char. Rust has no such restriction, and has no concept of strict aliasing like this. In Rust, "type aliasing" is allowed, so long as you respect size, alignment, and representability rules. Aliasing safety in Rust roughly means that you can not have an exclusive reference to an object if any other reference is active for that reference (reality is a little bit more involved than that, but not a lot). C has no such rule. It's very unfortunate that such similar names were given to these different concepts.
    - tialaramex 10mo ago
      No. Aliasing is a single idea, an alias is another name for the same thing. The concept translates well from its usual English meaning. The C "strict aliasing" rule is that with important exceptions the name for a thing of type T cannot also be an alias to a thing of type S, and char is an important exception. Linux deliberately switches off this rule. Rust's rule is that there mustn't be mutable aliases. We will see why that's important in a moment. Aliasing is an impediment to compiler optimisation. If you've been watching Matt's "Advent of Compiler Optimisation" videos (or reading the accompanying text) it's been covered a little bit in that, Matt uses C and C++ in those videos, so if you're scared of Rust you needn't fear that in the AoCO But why mutation? Well, the optimisations concern modification. The optimiser does its job by rewriting what you asked for as something (possibly not something you could have expressed at all in your chosen language) that has the same effect but is faster or smaller. Rewrites which avoid "spilling" a register (writing its value to memory) often improve both size and speed of the software, but if there is aliasing then spilling will be essential because the other aliases are referring to the same memory. If there's no modification it doesn't matter, copies are all identical anyway.

tialaramex 10mo ago

I guess the problem here is that you and the writer have different understandings of what "the error" means. The author is thinking about "the error" as some source code that's incorrect. "Your error was not bringing gloves and a hat to the snowball fight" but you're thinking "the error" is some diagnostic result that shows there was a problem. "My error is that I'm covered in freezing snow". Does that help?

informa23 10mo ago

[flagged]