3 ms·
Looking at the paper [0], this appears actively counterproductive. It mechanically removes the unsafe keyword from function declarations, but this does not make
by LegionMammal978 4y ago
Looking at the paper [0], this appears actively counterproductive. It mechanically removes the unsafe keyword from function declarations, but this does not make the code any safer! When you declare a function unsafe, it indicates that the caller must uphold certain preconditions that aren't implied by the type system alone: it doesn't change anything about the safety of the function's body.
Indeed, looking at the output of CRustS, it's creating "safe" functions that blindly read from and write to raw pointers that the caller passes in. This is unsound in a public API, since safe callers can pass in whatever values they want and cause UB. Even for an internal function, it defeats the entire point of marking it unsafe, since the unsafe body of the function has to account for every single caller to make sure that it is never being called incorrectly.
[0] https://doi.org/10.1145/3510454.3528640 https://doi.org/10.1145/3510454.3528640