Live data from Hacker News

Show HN: I built a Rust crate for running unsafe code safely

github.com

71–72 of 72 posts

Re: Show HN: I built a Rust crate for running unsafe code safely

#71
post #62

Earlier quoted context omitted.

> I'm referring to the fact that the rust code panics at the slightest sign of discomfort. That's kind of up to you as the developer though. I generally avoid writing functions that can panic -- I'd even argue any non-test code that panics is simply poorly written, because you can't "catch" a panic like you can in a high-level language. Better to return an error result and let the calling code decide how to handle it…

I agree with you that error results (and exceptions) are better than panics. I will point out, though, that we're talking about language proclivities. It is entirely up to you as the developer to write memory-safe code in C, and it's possible to do so. Most programmers don't because it's hard to do that once you're doing anything nontrivial. It's also possible to write panic-free rust, but it's hard.

That's fair. I do wish error handling in Rust were easier (try blocks have been in "unstable" for almost a decade). Panicking probably shouldn't have existed in the first place.

Re: Show HN: I built a Rust crate for running unsafe code safely

#72
post #67

This is likely to violate async-signal-safety [1] in any non-trivial program, unless used with extreme care. Running code in between a fork() and an exec() is fraught with peril; it's not hard to end up in a situation where you deadlock because you forked a multi-threaded process where one of the existing threads held a lock at the time of forking, among other hazards. [1] https://man7.org/linux/man-pages/man7/signal…

Thanks for that suggestion. I'm adding a few more limitations in this PR: https://github.com/brannondorsey/mem-isolate/pull/44 I know async-signal-safety is particularly important for, you know, signal handlers. But aside from those, and the multi-threading use case you describe, is there another use case where calling non async-signal-safe code from inside this module would lead to issues (that isn't covered in the…

At the risk of sounding overly harsh, I just don’t think this crate is a particularly good idea. I really do mean this as constructive criticism, so let me explain my reasoning.

A function being marked unsafe in Rust indicates that there are required preconditions for safely invoking the function that the compiler cannot check. Your “safe” function provided by this crate sadly meets that definition. Unless you take great care to uphold the requirements of async-signal-safety, calling your function can result in some nasty bugs. You haven’t made a “safe” wrapper for unsafe code like the crate claims, so much as you’ve really just traded one form of unsafety for another (and one that’s arguably harder to get right at that).

Post reply on HN