Hi,

cqwrteur (euloanty.delete@this.live.com) on July 11, 2021 11:58 am wrote:
> Brendan (btrotter.delete@this.gmail.com) on July 11, 2021 6:51 am wrote:
> > Michael S (already5chosen.delete@this.yahoo.com) on July 11, 2021 6:01 am wrote:
> > > Brendan (btrotter.delete@this.gmail.com) on July 11, 2021 1:54 am wrote:
> > > > cqwrteur (euloanty.delete@this.live.com) on July 10, 2021 6:27 pm wrote:
> > > > > Oh. Modern C++ does not save us. Neither C nor C++ are fixable. Using C or C++ will
> > > > > destroy the earth and kill everyone. Using C or C++ violates human rights.
> > > > >
> > > > > Okay. That is exactly the Rust advocator like you's logic. Alex Gaynor, one of the Rustsec
> > > > > evanglist (who is actually Rust dev) actively pushes Rust into Linux kernel because he
> > > > > treats C and C++ as some kind of great evil like hitler who violates human rights.
> > > > >
> > > > > Right. Clearly Linus Torvalds is the worst human rights violator
> > > > > in the world based on him and people like you's logic.
> > > >
> > > > Let's pretend that you are responsible for Linux and everyone blames you each time a new CVE
> > > > is found; and you want Linux to improve and be the best/most secure kernel it can be.
> > > >
> > > > Let's pretend you started by investigating the causes of the last 200 CVEs, and
> > > > found that there's lots of causes (CPU/hardware bugs that aren't the kernel's
> > > > fault at all, overflows, etc) but "memory safety" is one of the top causes.
> > > >
> > > > Now; what could you do?
> > >
> > > But does it matter?
> > > I mean, I believe that "memory safety" is one of the top causes, probably, in top 5 or even
> > > top 3, but I don't believe that it accounts for, say, more than 1/5th of all CVEs.
> > > I.e. it warrants attention, but very far from warranting such radical changes in methodology
> > > as switch to Rust that very likely has uncountable disadvantages vs current set of tools.
> >
> > It depends a lot on when you look and how you classify (and if you apply weights based on severity); but...
> >
> > For the current most recent 10 CVEs (from https://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2021/Linux-Linux-Kernel.html
> >
> > starting from "CVE-2021-34693 from 2021-06-14" in case it changes and you end up looking at newer list); it
> > looks like 60% could be classified as "memory safety" (parts
> > of a data structure are uninitialized, out-of-bounds
> > reads, 3 x use-after-free, out-of-bounds memory write = 6/10).
> >
> > It could be a fluke (a larger sample would be better); but it's at least plausible
> > to claim that "memory safety" the single largest cause of CVEs in Linux.
> >
> > Of course it's also plausible to classify differently, and possible to argue that Rust
> > won't avoid (some? most? all?) the memory safety issues, or that Rust will create new
> > problems, or that "found CVEs" are a lot less important than "not found CVEs".
>
> https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust
>
> Same with Rust crates and std. You still see 80% of cves are memory safety cves.
>
> Notice that this is only in crates. A lot of security vulnerabilities are not shown. Redox OS whatever.
>
> https://bugzilla.mozilla.org/buglist.cgi?bug_id=1513519%2C1683439%2C1690169%2C1690718
> https://phabricator.services.mozilla.com/D103999
>
> Things like Linux kernel, a monolithic single address kernel,
> you need a lot of unsafe. You will still find a lot of cves.
>
>
> If your argument is that parts of data structures are uninitialized, use-after-free, actually
> C++ reduces a huge amount of problem too, even you can add checks for preventing oob issues
> (that is what libstdc++ or C++ standard library is doing). Also unlike Rust, you can change
> existing C code to make them safer while Rust could only be used in new code.
>
> However, linus torvalds clearly does not like it and reasonable
> about it. And yes, C++ EH is a huge issue in kernel.
>
> So, Rust must prove it is superior to modern C++. However, Rust still requires a huge amount of runtime afaik,
> due to the bloat of rustfmt and all sorts of other stuffs. Clearly, using Rust is no better either.

Ah, I think I can see what's going on now. The reason you're not interested in finding out if Rust is/isn't better than C (after they start building safe code on top of the "unsafe scaffolding" you've been cherry picking) is that you're a butthurt C++ advocate.

With that in mind; I think you should start by clearly defining which subset of Cthulhu is your personal concept of "modern C++" this week. Not that it really matters, given that there's a 50% chance that "all the worst parts of C, with every fad feature conceivable slapped on top with no foresight over a 30+ year period" will add support for safe/unsafe in its next reincarnation anyway.

> Also recently I've found the stupidity like this:
> https://github.com/Rust-for-Linux/linux/commit/c606d85a0d3c67b8221fee5fa67028bdebd4b0cc#diff-521fe5c9ece1aa1f8b66228171598263574aefc6fa4ba06a61747ec81ee9f5a3
>
>
> Instead of doing this
> void foo()
> {
> p[1].x().y() = p[2].x().y();
> }
>
>
> Now you have to do this. Who the fuck in rust team though this is a good idea.
> ///SAFETY: p has 5 elements
> ///XXXX
> ///XXXX
> unsafe fn foo()
> {
> (unsafe{p.get_mut_unchecked(1)}.unsafe {x()}.unwrap().unsafe{y()?})? =
> (unsafe{p.get_mut_unchecked(2)}.unsafe {x()}.unwrap().unsafe{y()?})?;
> }
>
> Rust one is completely unreadable, wasting programmers time and probably even leading to slower compilation.

Unlike C++; where it's impossible to be sure what something as innocent looking as "a = b + c;" actually does without scouring the source code to determine who overloaded what; where compile times have a reputation for being the worst of any language ever created (despite scavenging the concept of modules from other languages and slapping it onto their huge pile recently)?

> If the goal of Rust team is to make everything painful, why should I waste time to fight against
> the compiler? Instead of using that time to sanitize and fuzz? What's the benefit of using it?

Heh. This is how I feel about "smart pointers" in C++. If the goal of C++ is to double the (already 10 times worse) learning curve why should I fight against the compiler?

Note: I'm not a Rust advocate (I'm just willing to let other people spend their time experimenting so I can obtain better empirical evidence about the benefits and pitfalls of certain language features). To me; the goal should be to reduce complexity of the language (because I think "more complexity" translates directly into "higher chance of mistakes" and that programmers have enough complexity to deal with from the problem their code is trying to solve), and to reduce the time between a programmer making a mistake and the programmer finding out a mistake was made (primarily by designing language to maximize the practicality and effectiveness of "continual analysis while you type").

- Brendan