Boone? There are plenty of fan boys out there that are selling rust like AI, or in other words snake oil.
Rust obviously has built in securities that C doesn’t have, but a shitty coder is a shitty coder and bad QC is bad QC. Now we’re seeing the reality of the consequences.
Rust and/or other memory safe® languages are like the future, but hopefully more people are now seeing the cracks. Just look at cloudflare for a prime example.
pryre@lemmy.world 1 month ago
I think the other takeaway here is that it was found in a section marked “unsafe”. At the very least, that’s a useful tool for the Devs to isolate potential problem areas. Comparing that to a pure C codebase where the problem could be anywhere.
hummingbird@lemmy.world 1 month ago
The funny part is: the fix does not change the unsafe block at all. The issue is elsewhere in safe rust code.
KexPilot@lemmy.world 1 month ago
No. The issue is that an assumption they make in the unsafe block does not actually always hold true. They changed the safe rust code to strenghten the assumption they made in the first place, because that is way easier than rearchitecting the unsafe part. I.e. if the unsafe part was somehow to be written safely, the mitigation they introduced now would not result in any difference in behaviour, it would be correct behaviour both before and after.
Tldr: the problem lies in the unsafe part
pryre@lemmy.world 1 month ago
I’ll admit, I haven’t looked at the code. I would stand by my comment of the unsafe block being a start point.
Countering that however, what is the difference to just debugging effectively? Not sure. I suppose it’s down to the people that identified it and fixed it at the end of the day to say if there was any benefit.
vrighter@discuss.tchncs.de 1 month ago
doesn’t change anything if you can’t avoid having to write the unsafe parts
nsfw936421@lemmynsfw.com 1 month ago
It certainly does. It’s way simpler to keep up all invariants and to review the few percent lines of code in unsafe blocks than making sure that the 30 million lines of code are free of undefined behavior.
Is some part of the code it battle tested of course it’s complete unreasonable to rewrite it in any language, but if you have to do a major rewrite anyway or write a new component you should definitely use a memory safe language. And no it doesn’t matter that there is an unsafe escape hatch because it’s literally impossible to write low level kernel stuff or FFI to other languages without unsafe because Rust can’t uphold/guarantee the invariants of the hardware itself or the behavior of other languages.