Nobody wants memory bugs. Penguinistas continue debate on how to squish 'em

Greg Kroah-Hartman… urged fellow contributors to embrace those interested in contributing Rust code to improve the kernel.

"Adding another language really shouldn’t be a problem… embrace the people offering to join us

Thoughts on this?

  • Dr. Moose@lemmy.worldEnglish
    417·
    19 hours ago

    I feel like better tooling is a safer bet. I know people hate on AI here but tooling that can detect flaws in C memory management would be basically as good as Rust itself.

    • sugar_in_your_tea@sh.itjust.worksEnglish
      2·
      3 hours ago

      True. We should have both better tooling and better languages. Someone posted this thread with Greg KH, which has this gem:

      The majority of bugs (quantity, not quality/severity) we have are due to the stupid little corner cases in C that are totally gone in Rust. Things like simple overwrites of memory (not that rust can catch all of these by far), error path cleanups, forgetting to check error values, and use-after-free mistakes. That’s why I’m wanting to see Rust get into the kernel, these types of issues just go away, allowing developers and maintainers more time to focus on the REAL bugs that happen (i.e. logic issues, race conditions, etc.)

      I’m all for moving our C codebase toward making these types of problems impossible to hit, the work that Kees and Gustavo and others are doing here is wonderful and totally needed, we have 30 million lines of C code that isn’t going anywhere any year soon. That’s a worthy effort and is not going to stop and should not stop no matter what.

      But for new code / drivers, writing them in rust where these types of bugs just can’t happen (or happen much much less) is a win for all of us, why wouldn’t we do this?

      In short, let’s do both.