121–130 of 150 posts
As someone that deals with a chromium-based codebase everyday, i dont think this is a good idea at all. Unnecessary overcomplication on the codebase, making it more difficult to understand. (Rust and C++ are complex beasts) The only thing i could think of, is to replace the tools that are mostly in Python.. But this will be a lot of work. I guess maybe Google wants to employ good Rust enginneers and need to have some…
Earlier quoted context omitted.
> So a lot of mistakes that are used as boogeyman to convince people to use Rust are barely problems you really face. https://bugs.chromium.org/p/project-zero/issues/list?q=produ... This year alone saw 2 issues from Project Zero in Chrome that would have been prevented by Rust - both OOB accesses, one with a helping of data racing. Chromium is an incredibly security-sensitive piece of software, and that really is an…
I have no doubt that Rust could save some sort of bugs. If you read all the comment i´ve made, you will see that we are talking about a massive codebase already coded in C++. Giving the time it is alive, all the engineering hours, investiments, tools, etc.. most of the bugs that Rust could have prevented right on the beggining are already covered (Chrome also uses fuzzers and static analysis tools to automate C++ cod…
This isn't even close to true...
https://chromereleases.googleblog.com/2020/08/stable-channel...
Here's one from just this month.
Here's another from just this month with another fifteen issues: https://chromereleases.googleblog.com/2020/08/stable-channel...
There are hundreds a year like this. I could find many, many, many more.
Earlier quoted context omitted.
math.h has M_PI in posix.
The point is that using macros for constants is frowned upon in modern codebases, just like all other use cases for macros that break type safety and the one definition rule.
Which actually highlights that many things you want to use for practical purposes are C rather than C++, predate innovations such as const or namespaces, etc. It's possible and common to understand the downsides and still reach for the macro.
Earlier quoted context omitted.
> The bar for safety is lower than you might expect, for example, crashing with a “panic” in case of an error is completely fine, that’s not considered unsafe. Yes, because "safety" in English is not analogous to "unsafe" in Rust in any real manner. They are linked only in the loosest conceptual way. Rust's "safety" and "unsafe" are well defined and exact, and can be objectively determined. In the English language it…
> That is, specifically AFAIK, not what it means in Rust. It's well defined there, so there's no need to resort to "the usual understanding". This causes a lot of confusion, but it doesn't need to. If someone is talking about the unsafe keyword in Rust, they're talking about Rust's definition of it and what it entails, or they're using incorrect terminology. I'd say that Rust is using incorrect terminology, since it…
Languages get to define their own terms. It's not rare for two languages to use terminology in similar, but different in fundamental ways, concepts. An extremely common example would be "threads".
In the case of "unsafe", we're not even really staying within the realm of software engineering to find a terminology mismatch in this case, we're going back to the English language itself (in which case almost all the keywords in any language might have a similar problem).
> No need for the “unsafe” keyword unless something is known to be less safe than normal C++. > For a Rustacean, this is controversial - all C++ is unsafe! Isn't this just a fundamental misunderstanding of what unsafe really means, and as such a nonsense goal that doesn't gain anything? Unsafe is a Rust language definition, and defines whether the rust compiler can vouch for the safety of some code. As such, calling…
The Rust definition of 'unsafe' is very far from the everyday meaning. Yeah you can mentally substitute 'rustc_cannot_vouch_for' but why can't Rust use a word closer in meaning to that in the first place? We tend to misuse everyday meanings I think. I reminded of 1. the msdos warning that 'this program has used an illegal instruction and will be shut down' 2. That DNS names with underscore are 'illegal'. This one cau…
"safe" is entirely relative in it's everyday meaning. To one person skydiving is safe, to another it is extremely unsafe. When you're a child your parent will tell you what is safe or not, but what your parent considers safe is based on their personal definition of safety.
The rust language will tell you if what you've done is safe based on its very well defined criteria for what that is, and won't let you proceed with something that doesn't match that criteria unless you vouch for it yourself. unsafe makes just as much sense here as any other word, it only seems a wrong fit when you look at it from a context it's not meant to be used in.
Earlier quoted context omitted.
Sure, but it does indicate something likely to be wrong, relative to normal rust code. If every C++ function is unsafe then it becomes less clear where the actually unsafe rust bits are.
C++ has made it very painless to upgrade from C, by being (mostly) a superset. It's so painless that many codebases haven't really upgraded and it's common to see C-isms sprinkled around larger code bases. Some classes written decades ago can survive the years written in horrible outdated style. For some that might be a feature, but for the quality (or safety) of the code it isn't. Yes, when there is too much unsafe…
> No need for the “unsafe” keyword unless something is known to be less safe than normal C++. > For a Rustacean, this is controversial - all C++ is unsafe! Isn't this just a fundamental misunderstanding of what unsafe really means, and as such a nonsense goal that doesn't gain anything? Unsafe is a Rust language definition, and defines whether the rust compiler can vouch for the safety of some code. As such, calling…
> ... known to be less safe than normal C++. Oh... no, no, that's... very unsafe lol. Jokes aside, making that their #1 goal was very strange. Agreed it appears to be a fundamental misunderstanding of what "unsafe" means. It doesn't mean that it's literally not safe to call that function, just that it's unchecked. "unchecked" might be a better annotation come to think of it.
“We are happy to empower our younger colleagues. We only ask they have 25 years of experience.”
Earlier quoted context omitted.
> Those are the only things unsafe Rust can do that safe Rust can't. It doesn't turn off the borrow checker or anything else. You can do serious damage with those things though. One tactic I have done is to expand the lifetime of a reference by laundering it through a raw pointer, since the function to convert a raw pointer to a reference allows you to choose any lifetime you want.
Yes, but good luck getting that through any form of code review. The unsafe block and the raw pointers or the call to transmute make it pretty obvious that something fishy is going on that’s worth reading carefully. ¯\_/(ツ)\_/¯ Unlike C or C++, where it can sometimes be harder to tell what the lifetime of something should be, or whether you’re extending the lifetime of a reference beyond the point that it is safe. Un…
do you think more than a few percent of the "foundational" OSS projects where we find all the classical CVEs have any code review process ?