4 ms·
Yes, pretty much like that. The author put "unsafe" blocks everywhere and the rest is history. Unsafe as a keyword is a kind of pledge: as a dev, you swear to t
by southerntofu 5y ago
Yes, pretty much like that. The author put "unsafe" blocks everywhere and the rest is history. Unsafe as a keyword is a kind of pledge: as a dev, you swear to the compiler that you've checked this part for correctness/safety. If you don't, you may get bitten, but the simple fact that "grep -R unsafe" will yield most (if not all) instances of potential memory fuckups is a huge win for auditability.
- pjmlp 5y agoRust's unsafe wouldn't have done anything to protect against an hypotetical log4r. As for the memory fuckups you are right, pity that they are using a C GUI library. Even if the binding has been deemed safe upon validation, if only remains a valid certification until the next Gtk version update, even minor ones might break the assumptions validated on the unsafe code block.
- southerntofu 5y ago> Rust's unsafe wouldn't have done anything to protect against an hypotetical log4r. You are correct. No programming language will protect you from writing flawed application logic. > pity that they are using a C GUI library. (...) Gtk version update, even minor ones might break the assumptions I don't know about that. GTK is more "battletested" than most frameworks, and has a lot of contributors to fix bugs. Also, and that's a very important point, GTK cares for accessibility! Using any other framework would have meant excluding a lot of people from the GUI. As for assumptions, i certainly hope GTK devs don't push breaking changes to the ABI on minor updates. But i guess that's yet another assumption that can be broken.