> 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.
> 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.
I 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.
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.