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

Experimenting with Rust in Chromium

chromium.googlesource.com

Post reply on HN
Print view View original

61–70 of 115 posts

Re: Experimenting with Rust in Chromium

#61

Post by sseagull »

saagarjha wrote: post #48
josefx wrote: post #41

Earlier quoted context omitted.

> 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.

> If you are using C strings in C++ you are either doing something incredibly low level or don't care about performance at all. …or interoperating with C code?

But the temporary copy only happens going from const char * to std::string, so the C code would have to be calling C++ code.

std::string to const char doesn’t (usually?) require copying.

Re: Experimenting with Rust in Chromium

#62

Post by seritools »

hoseja wrote: post #38
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…

psst... std::string_view

Ah yes, the one that still just wraps a raw pointer in the end

https://github.com/isocpp/CppCoreGuidelines/issues/1038

Re: Experimenting with Rust in Chromium

#63

Post by seritools »

secondcoming wrote: post #43
cletus wrote: post #10

Earlier quoted context omitted.

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…

That’s just poor software. A poor Rust dev would be one who clones everything.

`.clone()` is visible right in your code, though, unlike the implicit conversion/constructor magic.

Re: Experimenting with Rust in Chromium

#64

Post by pornel »

ncmncm wrote: post #54
blub wrote: post #50

Earlier quoted context omitted.

Based on the code changes made at that time, it seemed that Chrome developers didn’t know how to write performant C++ code. Those were not difficult to understand C++ features either, but basic ones which were very well known by then. I remember reading Bulka & Mayhew’s Efficient C++ (published in 2000) which mentioned the importance of avoiding copies, calling reserve and many other techniques. So your point is wron…

Yes. In two words, Google programmers are, as a rule, vastly overrated . They can maybe rope in 100,000 cores on one query, but nothing in their recruiting selects for good coding habits. Anybody coding C++ in this day'n'age and getting use-after faults needs to go to the back of the line. They will certainly succeed in writing new Rust code that is as bad as their old C++ code. (Note: deadlocks are officially "safe"…

So where are those mythical "good C++ programmers"? I keep hearing that if only you find them, your C++ will be secure. But so far nobody has found them. Not Google, not Microsoft, not Mozilla.

Rust succeeds, because it does not rely on programmers writing bug-free code. Bad Rust code is not as dangerous as bad C++ code.

BTW: deadlocks are not exploitable for RCE, and are quite easy to debug compared to data races and heap sprays.

Re: Experimenting with Rust in Chromium

#65

Post by vlovich123 »

mseepgood wrote: post #18
cletus wrote: post #10

Earlier quoted context omitted.

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…

How would Rust help here? Isn't it famous for having too many string types?

Everyone’s trying to justify the response when the honest truth is that no, Rust doesn’t solve the problem of abstraction layer impedance mismatches causing ownership to be dropped only to be reacquired at the next level. On a sufficiently large/complicated code base, the problem will arise.

As others have mentioned, various kinds of string types are baked into the language which makes it ergonomic to do “the right thing” from the get go, but hard to say. I would be skeptical of claims that it would make a difference, especially in the interim where you now have an added impedance mismatch with C++, Rust, C.

Re: Experimenting with Rust in Chromium

#66

Post by sseagull »

seritools wrote: post #63
secondcoming wrote: post #43

Earlier quoted context omitted.

That’s just poor software. A poor Rust dev would be one who clones everything.

`.clone()` is visible right in your code, though, unlike the implicit conversion/constructor magic.

But you could write a C++ class with a manual .copy() method and a deleted copy constructor (and other conversion constructors not implemented).

Doing that seems a bit easier than integrating a whole new language into your project (although I know Rust would have other benefits).

Re: Experimenting with Rust in Chromium

#67

Post by pornel »

brabel wrote: post #58
staticassertion wrote: post #25

Earlier quoted context omitted.

Yes, I believe literally every single 'in the wild' exploit has abused memory unsafety, as well as hundreds of vulnerabilities every year.

That's strange... if they'd written the code in a memory safe language, say, Java... there wouldn't be any vulnerability? I don't know... I see plenty of vulnerabilities in the Java world, no memory unsafety needed.

Yes, if they used Java then a whole class of use-after-free exploits wouldn't be possible.

Security is not a binary yes/no. There are many many ways in which programs can be insecure. Eliminating one class of bugs helps reduce total amount of issues and their severity.

It's like car crashes: cars with seatbelts, airbags, and auto-braking systems kill way fewer people than they used to, but are still deadly.

Re: Experimenting with Rust in Chromium

#68

Post by mkj »

ncmncm wrote: post #54
blub wrote: post #50

Earlier quoted context omitted.

Based on the code changes made at that time, it seemed that Chrome developers didn’t know how to write performant C++ code. Those were not difficult to understand C++ features either, but basic ones which were very well known by then. I remember reading Bulka & Mayhew’s Efficient C++ (published in 2000) which mentioned the importance of avoiding copies, calling reserve and many other techniques. So your point is wron…

Yes. In two words, Google programmers are, as a rule, vastly overrated . They can maybe rope in 100,000 cores on one query, but nothing in their recruiting selects for good coding habits. Anybody coding C++ in this day'n'age and getting use-after faults needs to go to the back of the line. They will certainly succeed in writing new Rust code that is as bad as their old C++ code. (Note: deadlocks are officially "safe"…

I don't normally want to be personal, but ncmncm you chime in with this thread each time. Can you give an example of what you yourself have written that would live up to your standards? I'm curious what type of thing you're talking about.

Re: Experimenting with Rust in Chromium

#69

Post by jcelerier »

tialaramex wrote: post #42
gary_0 wrote: post #36

Earlier quoted context omitted.

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.

> the ancient past before the STL was fully standardized Specifically the "ancient past" here is prior to C++ 11 when C++ decided now it wanted to actually define how its string type works because C++ 98 and C++ 03 strings are both even more dangerous than most things are in C++ and had to be put out of their misery.

> because C++ 98 and C++ 03 strings are both even more dangerous

... how so ? they were just CoW which is actually I think the better choice most of the time... now there are copies all over the place

Re: Experimenting with Rust in Chromium

#70

Post by lordofgibbons »

pjmlp wrote: post #35
nikeee wrote: post #13

> The language, at least for now, is Rust. What are the alternatives in the context of Chromium development as a replacement for C++?

https://www.chromium.org/Home/chromium-security/memory-safet... See "Using safer languages anywhere applicable".

Interesting that Java, Swift, and Javascript are listed there but not Go. I wonder why
Post reply on HN