Hacker News Reader

Comment by blegge | Hacker News Reader

> arena-based tree with zero unsafe in the public API

Why "in the public API"? Does this imply it's using unsafe behind the hood? If so, what for?

I agree the wording is a bit strange, but a quick grep of the repo shows that it doesn't imply that.

The only usages of unsafe are in src/ffi, which is only compiled when the ffi feature is enabled. ffi is fundamentally unsafe ("unsafe" meaning "the compiler can't automatically verify this code won't result in undefined behavior") so using it there is reasonable, and the rest of the crate is properly free of unsafe.

It provides a libxml2-compatible C API and that accepted pointers, this would seem to necessitate unsafe at least.

Yeah I'm a bit confused because you can have an entirely unsafe code base with just the public interface marked as safe. No unsafe in the interface isn't a measure of safety at all.

It is a measure of the intended level of care that the users of your interface have to take. If there's no unsafe in the interface, then that implies that the library has only provided safe interfaces, even if it uses unsafe internally, and that the interface exposed enforces all necessary invariants.

It is absolutely a useful distinction on whether your users need to deal with unsafe themselves or not.

Sure, it's a useful distinction for whether users need to care about safety but not whether the underlying code is safe itself, which is what I wrote about.

No or very little but verified unsafe internal code is the bar for many Rust reimplementations. It would also be what keeps the code memory safe.

I guess I don't write enough rust to say this with confidence, but isn't that the bare minimum? I find it difficult to believe the rust community would accept using a library where the API requires unsafe.

>I guess I don't write enough rust to say this with confidence, but isn't that the bare minimum

I have some experience and yes, unless you're putting out a library for specifically low-level behavior like manual memory management or FFI. Trivia about the unsafe fn keyword missed the point of my comment entirely.

Not at all. Some things are fundamentally unsafe. mmap is inherently unsafe, but that doesn’t mean a library for it shouldn’t exist.

If you’re thinking of higher level libraries, involving http, html, more typical file operations, etc, what you’re saying may generally be true. But if you’re dealing with Direct Memory Access, MCU peripherals, device drivers, etc, some or all of those libraries have two options: accept unsafe in the public interface, or simply don’t exist.

(I guess there’s a third option: lie about the unsafety and mark things as safe when they fundamentally, inherently are not and cannot be safe)

Yeah I didn’t want to get into the weeds about inherently unsafe stuff, since the OP was about an XML parser

It's useful, to be sure, but I wouldn't want to use a library with a safe public interface that is mostly unsafe underneath (unless it's a -sys crate, of course). I think "this crate has no unsafe code" or "this crate has a minimal amount of carefully audited unsafe code" are good things to see, in general.

Reply on news.ycombinator.com