Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust and C++ Interoperability in Chrome

chromium.org

Post reply on HN
Print view View original

11–20 of 150 posts

Re: Rust and C++ Interoperability in Chrome

#11

Post by roblabla »

steveklabnik wrote: post #8
rightbyte wrote: post #5

Earlier quoted context omitted.

Can't you just do a: #define CPP_CALL unsafe in the Rust equivalent to annotate "unsafe" cpp calls from Rust? "No boilerplate or redeclarations. No C++ annotations. Ideally, no allowlist." This seems like an unpractical approach. How do you even call C++ code from Rust without extern "C" linkage.

Rust does not have a textual substitution pre-processor, so like, you can do this sorta kinda but it would be way more involved.

    macro_rules! cpp_call {
        ($($tt:tt)*) => {
            unsafe { $($tt)* }
        }
    }
Yeah, not pretty, but it works :P

Re: Rust and C++ Interoperability in Chrome

#12

Post by muizelaar »

brian_herman__ wrote: post #2

I wonder how this compares to Mozilla's approach when they did something similar with Rust, Firefox and servo.

Mozilla's uses a combination of https://github.com/eqrion/cbindgen and https://github.com/rust-lang/rust-bindgen depending on the direction of interop. These tools don't provide the safety guarantees of https://github.com/dtolnay/cxx but the also both predate cxx and C++ doesn't have much in terms of safety guarantees to begin with so the bar is pretty low.

Re: Rust and C++ Interoperability in Chrome

#14

Post by luizfelberti »

steveklabnik wrote: post #8
rightbyte wrote: post #5

Earlier quoted context omitted.

Can't you just do a: #define CPP_CALL unsafe in the Rust equivalent to annotate "unsafe" cpp calls from Rust? "No boilerplate or redeclarations. No C++ annotations. Ideally, no allowlist." This seems like an unpractical approach. How do you even call C++ code from Rust without extern "C" linkage.

Rust does not have a textual substitution pre-processor, so like, you can do this sorta kinda but it would be way more involved.

> Rust does not have a textual substitution pre-processor

Is that not pretty much what Rust's procedural macros are? [0]

Except for the fact that they do not allow emitting invalid token streams (which is something you don't want anyways), it can do any arbitrary manipulation of source code, but in a way that is integrated with the compiler and less prone to breaking the program.

[0] https://doc.rust-lang.org/reference/procedural-macros.html

Re: Rust and C++ Interoperability in Chrome

#15

Post by fullstop »

steveklabnik wrote: post #8
rightbyte wrote: post #5

Earlier quoted context omitted.

Can't you just do a: #define CPP_CALL unsafe in the Rust equivalent to annotate "unsafe" cpp calls from Rust? "No boilerplate or redeclarations. No C++ annotations. Ideally, no allowlist." This seems like an unpractical approach. How do you even call C++ code from Rust without extern "C" linkage.

Rust does not have a textual substitution pre-processor, so like, you can do this sorta kinda but it would be way more involved.

I keep meaning to dive into Rust, but it feels like they've removed so many useful things in the name of safety.

I mean, I get it, these are all things which can be used to very easily cause chaos and shoot yourself in the foot. I look at code that I've written, though, and see so many challenges to writing the same thing in Rust.

I spend 99% of my time in embedded Linux or bare metal, though, so maybe my view point is a bit skewed.

There seem to be very few GUI libraries which can be used in Rust as well. I'll keep checking https://areweguiyet.com/

Re: Rust and C++ Interoperability in Chrome

#16

Post by coder543 »

rightbyte wrote: post #5
bluejekyll wrote: post #4

> This seems to present some C++/Rust interoperability challenges which nobody else has faced. Is this different from the Firefox integration with Rust in some meaningful way? It looks like the cxx library is going to be critical for this. I’m curious how helpful others have found cxx for interop with C++? > For a Rustacean, this is controversial - all C++ is unsafe! But “unsafe” should be a really bad code smell. If…

Can't you just do a: #define CPP_CALL unsafe in the Rust equivalent to annotate "unsafe" cpp calls from Rust? "No boilerplate or redeclarations. No C++ annotations. Ideally, no allowlist." This seems like an unpractical approach. How do you even call C++ code from Rust without extern "C" linkage.

Really, your text macro substitution is missing the broader point.

Hiding the word "unsafe" doesn't make it any less unsafe.

The Rust compiler can't guarantee that the C++ code being called doesn't have use-after-free bugs or buffer overflows.

The Rust compiler can't guarantee that pointers being returned from C++ code aren't just wild pointers that point in the middle of nowhere.

The Rust compiler can't guarantee that the C++ code isn't mutating into an immutable reference.

The Rust compiler can't guarantee that the C++ code isn't holding onto a reference to an object that it will later mutate when Rust thinks it is now the sole owner of that object.

The Rust compiler can't guarantee that the C++ code isn't sending un-Send objects across threads, or that it isn't deallocating objects that it isn't supposed to deallocate.

Rust makes a lot of guarantees about code written in Rust, which is why people are so passionate about it. The Rust compiler feels like having the world's best static code analyzer at your fingertips. It's really nice.

C and C++, on the other hand, are each full of an assortment of powerful footguns. Well-written C or C++ code interops very nicely with Rust, but the problem is that programmers are only human, and humans have been repeatedly shown to make mistakes.

So, calling C++ code is unsafe, and unsafe is a code smell because it is an opportunity for guarantees to be violated, which is undefined behavior.

Ideally, you build an abstraction around the unsafe interop layer that rigorously enforces every requirement that the C or C++ code expects (but that the C and C++ compilers cannot enforce), so that the external code will behave as well as it can.

The Chromium document is right to call their idea controversial. Hiding the unsafety of the C++ code without actually doing anything to protect against malformed calls to that C++ code is a loaded footgun. It might be the right call for this specific case, though.

Re: Rust and C++ Interoperability in Chrome

#17

Post by nitsky »

eggsnbacon1 wrote: post #10

Do they really need to access thousands of C++ API calls from Rust? Doesn't this defeat the purpose of writing safe code in Rust? This smells of "not invented here" which applies to Google projects pretty often. They should focus on integrating Rust in portions of the API instead of exposing a gigantic unsafe API surface, essentially making all their code unsafe. Unless the Chrome codebase is really such a mess that…

> Doesn't this defeat the purpose of writing safe code in Rust?

While the Chrome authors will not be protected from memory unsafety in the wrapped C++ APIs, the usage of those APIs in the new code they write on top will be safe, which is better than nothing. Similarly, much of the Rust standard library and many popular crates are "safe" wrappers around unsafe code, like calls to libc, winapi, openssl, etc. If there is a memory unsafety issue in one of those libraries, Rust won't save you.

Re: Rust and C++ Interoperability in Chrome

#18

Post by jcranmer »

muizelaar wrote: post #12
brian_herman__ wrote: post #2

I wonder how this compares to Mozilla's approach when they did something similar with Rust, Firefox and servo.

Mozilla's uses a combination of https://github.com/eqrion/cbindgen and https://github.com/rust-lang/rust-bindgen depending on the direction of interop. These tools don't provide the safety guarantees of https://github.com/dtolnay/cxx but the also both predate cxx and C++ doesn't have much in terms of safety guarantees to begin with so the bar is pretty low.

It's also worth mentioning that Mozilla tends not to use a lot of standard C++ types, using nsTArray instead of std::vector or nsA?C?String instead of std::string. This makes the porting of APIs using arrays or structs easier, since Mozilla owns the ABI rather than needing to worry about different standard libraries having different ABIs.

Re: Rust and C++ Interoperability in Chrome

#19

Post by the8472 »

bluejekyll wrote: post #4

> This seems to present some C++/Rust interoperability challenges which nobody else has faced. Is this different from the Firefox integration with Rust in some meaningful way? It looks like the cxx library is going to be critical for this. I’m curious how helpful others have found cxx for interop with C++? > For a Rustacean, this is controversial - all C++ is unsafe! But “unsafe” should be a really bad code smell. If…

I assume the cxx library still generates unsafe code, but that can be excluded from analysis, i.e. no human-written unsafe is needed.

Re: Rust and C++ Interoperability in Chrome

#20

Post by ChrisSD »

fullstop wrote: post #15
steveklabnik wrote: post #8

Earlier quoted context omitted.

Rust does not have a textual substitution pre-processor, so like, you can do this sorta kinda but it would be way more involved.

I keep meaning to dive into Rust, but it feels like they've removed so many useful things in the name of safety. I mean, I get it, these are all things which can be used to very easily cause chaos and shoot yourself in the foot. I look at code that I've written, though, and see so many challenges to writing the same thing in Rust. I spend 99% of my time in embedded Linux or bare metal, though, so maybe my view point…

If you want to use a tool that pastes code fragments in arbitrary places you can. However, I'm not clear on the benefit over something that's aware of its context, or at the very least AST aware.
Post reply on HN