[Info-vax] Rust as a HS language, was: Re: Quiet?

[Dan Cross]

In article <t2q8jm$334$1 at dont-email.me>,
Simon Clubley  <clubley at remove_me.eisner.decus.org-Earth.UFP> wrote:
>Yes, it is. I included it because it was one of the first articles
>Google returned to me when I did a search for Rust language articles.

I can tell you with some assurance that those results tend to be
different for different people.

>To go back to one of the examples I posted recently (which I picked at
>random from a list of Rust CVEs):
>
>https://rustsec.org/advisories/RUSTSEC-2020-0148.html
>
>|Affected versions of this crate have the following issues:
>|
>|Ptr implements Send and Sync for all types, this can lead to data races by
>|sending non-thread safe types across threads.
>|
>
>Avoiding data races is advertised as a core feature of Rust and this
>library managed to violate that rule.

Yes, and this library uses `unsafe` trait impls to violate the
core guarantees that give data race freedom: the semantics of
`Send` and `Sync`.  These are what let you do things like
trivially send values like `5` between threads.  If you abuse
those in an unsafe manner you can't claim that your code is
data race free anymore.

>|Ptr::get violates mutable alias rules by returning multiple mutable
>|references to the same object.
>
>_This_ violates the core feature of Rust which is the borrow checker.

Actually, no, it doesn't: note that the code in question uses
`unsafe` to manufacture mutable _references_ from a raw pointer
contained inside the object in question.  This is one reason why
indirecting a raw pointer is _always_ unsafe.

>|Ptr::write uses non-atomic writes to the underlying pointer. This means
>|that when used across threads it can lead to data races.
>
>Another data races problem.

Another `unsafe` violation of the language's semantics.

>I'd call the above examples of the complete bypassing of Rust's unique
>features. And it doesn't even matter how they did it. What matters is
>that they did.

You might, but that's because bluntly, you neither know nor
understand the language.

>Just this one CVE shows the borrow checker being bypassed and the
>eliminating data races feature of Rust also being bypassed.

No it does not.  That you assert that it does shows that you
neither know what the borrow checker is nor what it purports to
do.

>I also posted another example of a traditional buffer overflow issue.
>
>I would call this all memory safety being disabled, so no, it's not
>my imagination.

"Programmer writes bad library; creates bugs.  Film at 11!"

>Would be nice if those articles pointed that out instead of gushing
>over Rust in the same way as people did over Java in the early days.

This I agree with.

	- Dan C.