4 ms·
You either haven't looked at how cxx works, or you're intentionally misrepresenting it. cxx generates code that uses `unsafe` blocks/functions. It then generat
by cornstalks 6y ago
You either haven't looked at how cxx works, or you're intentionally misrepresenting it.
cxx generates code that uses `unsafe` blocks/functions. It then generates safe wrappers around those, which are what it exposes to users. It's no different then someone doing this:
pub fn safe_fn() {
extern { fn unsafe_fn(); }
unsafe { unsafe_fn(); }
}
cxx just uses macros to generate that. You're welcome to have a different opinion on whether or not the user must pass an `unsafe` token to the macro. But that has no bearing on the code generated by the macro.
Statements like "Party A wanting safe Rust to have undefined behavior was wrong" are just straight up incorrect.
- Jweb_Guru 6y agoSomeone doing what you just described is wrong in the context of C++, at least without manual review.
- fluffything 6y agoI know how cxx works, and I am not misrepresenting anything. cxx is currently unsound, and the author (dtolnay) has chimed in above with a fix they are considering that fixes it (https://news.ycombinator.com/item?id=24244121 https://news.ycombinator.com/item?id=24244121) The API of the cxx crate is safe, and it can cause UB, therefore it is unsound. It doesn't matter that the cxx crate API is a macro. Yes, this macro expands to unsafe code like you mention, but the problem is that this unsafe code is often "broken" (unsound).
- Ar-Curunir 6y agoUnsafe != unsound
- fluffything 6y agoI know. The Rust spec defines "unsound" as "introducing undefined behavior in safe Rust". The API of the cxx crate allows a safe Rust program to have undefined behavior, and it is therefore unsound.