News for hackers. Stuff that matters.
Re:Bugs Rust Won't Catch by gblargg on Wednesday April 29, 2026 @03:53AM (#47945334)
Rewriting perfectly good code was a colossal mistake.
Re:Bugs Rust Won't Catch by Cthulhu_ on Wednesday April 29, 2026 @05:25AM (#47945987)
Not necessarily, but was the reasoning sound and have the tradeoffs been made? The website (https://uutils.github.io/) shows some reasonable "why"s (although I disagree with making "Rust is more appealing" a compelling reason, but that's just me (disclaimer: I don't like C and don't know Rust so take this comment as you will)), but I think what's missing is how they will ensure both compatibility and security / edge case handling, which requires deep knowledge and experience in the original code and "tribal knowledge" of deep *nix internals.
Re:Bugs Rust Won't Catch by dwattttt on Wednesday April 29, 2026 @05:48AM (#47946148)
I do wonder whether people got down the article enough to see the list of bugs patched in GNU coreutils.

That "perfectly good code" that it sounds like no one should question included "split --line-bytes has a user controlled heap buffer overflow".

Re:Bugs Rust Won't Catch by gblargg on Wednesday April 29, 2026 @08:29AM (#47947414)
Yes, perfectly good code can have bugs. This is ridiculous thinking to scrap a codebase because it's not bug-free, to replace it with one riddled with differences in behavior that break everything that uses it.
Re:Bugs Rust Won't Catch by kibwen on Wednesday April 29, 2026 @09:36AM (#47948281)
The irony here being that GNU's coreutils themselves originated as rewrites, from back when BSD's copyright status was still legally unclear.
Re:Bugs Rust Won't Catch by gblargg on Wednesday April 29, 2026 @10:47AM (#47949200)
Understandable as GNU was founded on software freedom. I guess one could argue that the Rust rewrite is to establish some kind of higher standard for correctness.