Experimenting with Rust in Chromium

Post by tialaramex » Wed, Jun 22, 2022, 8:20 AM UTC

gary_0 wrote: post #36

imron wrote: post #16

Earlier quoted context omitted.

> The C++ designers allowed you to avoid friction here by allowing you to pass a std::string to a function expending a const char . Technically, this is an operator method. It's the other way round. You can pass a const char* to a function expecting a std::string. Passing a std::string to a function expecting const char* will generate a compile error. You need to call c_str() on the std::string if you want to pass it…

I'm not sure if this is what OP was referring to, but in the ancient past before the STL was fully standardized, some implementations had an `operator const char*` in std::string to allow implicit conversions.

Post by IshKebab » Wed, Jun 22, 2022, 8:51 AM UTC

flohofwoe wrote: post #28

Gigachad wrote: post #15

Earlier quoted context omitted.

For me, the fact that the Linux project has decided that Rust will be included in the kernel was the point Rust has become a success. It's pretty clear at this point that Rust will be around for decades and start to replace the well established C space.

> the Linux project has decided that Rust will be included in the kernel Isn't this a bit oversimplified? IIRC the Rust support was only started as an option for writing device drivers in Rust, not actual kernel code, and even this relatively simple use case looks like a herculean effort which required changes to feed back into Rust - which is a good thing of course, but currently it looks like the Rust ecosystem ben…

Post by selfmodruntime » Wed, Jun 22, 2022, 9:19 AM UTC

staticassertion wrote: post #27

imron wrote: post #26

Earlier quoted context omitted.

About 70% of all exploits: https://www.chromium.org/Home/chromium-security/memory-safet...

Just to clarify, exploit generally refers to software that takes advantage of vulnerabilities, vulnerabilities are the flaws themselves. As in, one writes code to "exploit" a "vulnerability". 70% of all vulnerabilities reported to them are memory safety issues. To my knowledge, 100% of exploits against Chrome in the wild leverage memory unsafety.

Post by saagarjha » Wed, Jun 22, 2022, 9:42 AM UTC

josefx wrote: post #41

imron wrote: post #23

Earlier quoted context omitted.

It's the 'too many string types' that helps. With C++, if you have char*'s (because you don't need to own the memory) and you pass it to a function that takes a const std::string& (because it also doesn't want to own the memory), then there will still be an implicit conversion to a temporary std::string (involving an allocation) despite neither the caller or the callee needing to own any memory. With Rust, if you hav…

> With C++, if you have char*'s (because you don't need to own the memory) If you are using C strings in C++ you are either doing something incredibly low level or don't care about performance at all. C strings require strlen calls or something equivalent for basic operations and you can easily run into code with exploding runtime if you aren't extremely careful.

Post by blub » Wed, Jun 22, 2022, 9:57 AM UTC

cletus wrote: post #10

riwsky wrote: post #7

Even though it'd be a while before this really affects the Chrome codebase, it's a real testament to how well Rust nails the safe-but-low-level niche. Google does not lack resources to tool (or staff!) a C++ codebase correctly, nor does it lack resources to build languages[1] targeting these specific problems; that they'd consider Rust isn't just because "it's there". [1] https://github.com/google/wuffs

Story time. I worked at Google years ago and there was a presentation once done on some optimizations done on Chrome performance. This is probably 10 years ago now. So C++ has std::string of course. C libraries however use "const char ", which has lots of problems. The C++ designers allowed you to avoid friction here by allowing you to pass a std::string to a function expending a const char . Technically, this is an…