Hacker News Reader

Comment by fluffything | Hacker News Reader

> However, what I see is the user of cxx/autocxx saying "I am asserting that this API is sound."

And since the API of this library allows this assertion to be performed in safe Rust code, when it fails, safe Rust code has UB, which according to the Rust language reference makes the API of this crate unsound.

Unsound safe Rust APIs are broken Rust code. The Rust language spec and toolchain make no guarantees about what the behavior of these APIs is.

So that's what I see here. Just another safe Rust API that is broken by design. Maybe with the twist that this crate is actually a factory to generates thousands of those broken safe Rust APIs in masse, which kind of makes it worse than your usual "broken API" bug (which is what these are, these are soundness bugs in Rust libraries).

View on HN

> this assertion to be performed in safe Rust code,

This assertion is always performed in safe Rust code. That's how you turn unsafe code into safe code: you write "unsafe { }" in safe code. That this does this in the body of a macro is not material.

(I know you disagree and don't think we're going to get anywhere, and frankly, find your aggressiveness really offputting.)

> This assertion is always performed in safe Rust code.

Safe Rust code performs these assertions by using the "unsafe" keyword. This library API allows safe Rust to perform these assertions _without_ writing "unsafe".

That's the problem.

Do you think that macros should treat unsafe blocks in their body as a compiler error? Because that's what this boils down to.

If so, why? How is that materially different from calling a function with unsafe in its body? If not, why is this particular macro different?

> Do you think that macros should treat unsafe blocks in their body as a compiler error?

No. Exported macros (as opposed to private ones) are only sound if they do not allow safe Rust to introduce undefined behavior.

Whether these macros use "unsafe" internally or not is irrelevant. For example, `pin_mut!` uses unsafe internally, but it does not allow safe Rust calling it to introduce UB.

A macro that allows safe Rust to introduce undefined behavior is unsound. An example of such an unsound macro would be `offset_of!`.

---

That is, I do not differentiate Rust abstractions when it comes to soundness. Whether its a function, a trait method, a macro, or a function pointer, it does not matter. If an abstraction its safe to use it shall not introduce UB. If it does, it is an unsound abstraction.

> Exported macros (as opposed to private ones) are only sound if they do not allow safe Rust to introduce undefined behavior.

There is no debate about this.

You didn't really answer my question. I'm also not really gonna continue this argument.

> There is no debate about this.

Of course there is, for example, the offset_of! macro was unsound for a long time:

* https://internals.rust-lang.org/t/pre-rfc-add-a-new-offset-o...

* https://github.com/rust-lang/unsafe-code-guidelines/issues/1...

* https://github.com/rust-lang/unsafe-code-guidelines/issues/2...

* https://github.com/rust-lang/rust-memory-model/issues/35

> You didn't really answer my question.

I literally wrote "No.". To your follow up questions starting with "If so ..." i did not reply, because the assumption these questions were based on (that I would reply to the previous question with "yes") did not hold.

To expand on this. Rust does not have "unsafe macros", so all exported macros must be sound. Whether a macro is sound or not is orthogonal to whether the macro itself uses `unsafe` (and your original claim was whether I thought that macros containing unsafe should be rejected by the compiler, to which I replied "No.", `pin_mut!` is an example of a macro that uses `unsafe` and is sound).

I'm observing this discussion as an outsider and can't help but wonder: maybe this could be solved by renaming the macro in question so that it contains "unsafe" in its name?

Whoever invokes the macro asserts that doing so is sound / cannot cause UB, and having "unsafe" in the macro name draws attention to that in the same way that the unsafe keyword itself does.

That is what in fact is being proposed by the author of this library (well the one this library depends on) elsewhere in this thread. I think it's a great idea.

Reply on news.ycombinator.com