3 ms·
Rust modules using unsafe can be pretty self-contained and small. For this particular library, most unsafe blocks are for calling glibc functions via FFI. They
by fluffything 7y ago
Rust modules using unsafe can be pretty self-contained and small.
For this particular library, most unsafe blocks are for calling glibc functions via FFI. They could probably use nix to avoid unsafe in FFI with libc.
- cyphar 7y ago> They could probably use nix to avoid unsafe in FFI with libc. Though nix also just wraps the FFI unsafe blocks. I'm also very "meh" on nix -- it seemed like a neat project when I first started looking into using it but the interfaces they provide make it harder and less idiomatic to hook into libc. For instance, all of the *Set interfaces are significantly more annoying to use than just bitwise or in C.
- fluffything 7y ago> Though nix also just wraps the FFI unsafe blocks. So? How they provide safe APIs doesn't matter, what matters is that they are safe. If the C FFI API is always safe for all inputs, then wrapping it in an unsafe block is the right thing to do. > but the interfaces they provide make it harder and less idiomatic to hook into libc. The interfaces they provide are both safe and portable over pretty much all UNIX-like systems (MacOSX, Linux, FreeBSD, OpenBSD, NetBSD, DragonflyBSD, Solaris, ...). libc interfaces are platform specific.
- cyphar 7y agoI agree that unsafe { libc::foo() } is generally fine assuming the inputs are sane, but my point was more that nix is somewhat of a glorified unsafe wrapper that isn't always necessary. But my issue with nix wasn't portability, it's that quite a few of the APIs they provide are more-frustrating-than-necessary.