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

[Dan Cross]

In article <t2q1u3$ddm$1 at dont-email.me>,
Simon Clubley  <clubley at remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2022-04-07, Dan Cross <cross at spitfire.i.gajendra.net> wrote:
>> In article <t2na4b$sdf$1 at dont-email.me>,
>> Simon Clubley  <clubley at remove_me.eisner.decus.org-Earth.UFP> wrote:
>>>For example, articles that, instead of taking a balanced approach, spend
>>>the first 95% of the article saying how great and perfect Rust is, and only
>>>in the last 5% (if at all) start mentioning in passing the unsafe stuff
>>>"for when you really need to do that stuff".
>>
>> Could you perhaps provide a citation to one of these articles?
>>
>
>Interesting question. I obviously can't remember the locations of
>the articles I found in the past, so I looked at a small sample of
>articles returned by Google to see if I had problems with them.

It's worth pointing out immediately that none of these are in
any way "official".  I'm sure I could find a number of similar
publications by, say, Ada neophytes, those enamoured with Lisp
but not skilled in that language, etc, that would have similar
issues.

>Comments below.
>
>https://dev.to/katholder/pros-and-cons-of-rust-language-313i
>
>Obviously a gushing user type writeup with non of the serious
>analysis and flaws such as unsafe code you would expect to see.
>
>https://codilime.com/blog/why-is-rust-programming-language-so-popular/
>
>Mentions briefly unsafe mode but doesn't make it clear that you can
>invalidate _all_ the unique features and guarantees in Rust when you
>use it. It makes it sound like it's some obscure thing that only affects
>writing to memory like in C or C++. It also has this little gem:

You _don't_ invalidate _all_ the unique features and guarantees,
though.  At least not without going ridiculously out of you way.

>|Rust's dual-mode model is one of its biggest advantages. In C++, on the
>|other hand, you never know you've written unsafe code until somewhere down
>|the line your software crashes or a security breach rears up.

My reading of that excerpt is that the author is saying that in
C++ all code is de facto unsafe, and you have no notion of way
to tell if code is safe.  In rust, writing unsafe code is
explicit.

>Seriously ? In Rust unsafe mode, you have the same problem and C++ has
>a number of features that allow programmers to build more robust self
>checking code (although I wish, for example, [] was bounds checked and
>that it wasn't delegated to .at() to enforce bounds checking. at() would
>have been better as the unchecked version so you had to make a positive
>decision to do that).

Well, that's correct.  But most Rust code isn't unsafe.  C++ has
no analogous concept.

>https://www.infoworld.com/article/3218074/what-is-rust-safe-fast-and-easy-software-development.html
>
>Based on the complete bypassing of Rust's unique features seen in the
>CVEs when running in unsafe mode, the following is either wrong or at
>least misleading depending on how you look at it:
>
>|Rust lets you live dangerously if you need to, to a point. Rust's safeties
>|can be partly suspended where you need to manipulate memory directly, such
>|as dereferencing a raw pointer a la C/C++. The key word is partly, because
>|Rust's memory safety operations can never be completely disabled. Even
>|then, you almost never have to take off the seatbelts for common use cases,
>|so the end result is software that's safer by default.
>
>Can never be fully disabled ? There are a set of CVEs that say otherwise.

No, the author is correct; your mistake is that you do not know
what all of the safety guarantees are.  For instance, unsafe
does not turn off the borrow checker, so unless you _really_ go
out of your way to create an invalid reference, you continue to
get the benefits of that.  Of course, you can do something weird
like cast a reference to an integer, drop the referent, and then
cast that integer back to a reference, but at that point you're
going out of you way to violate the rules of the language, and
recall that the contract around `unsafe` is that the programmer
agrees to take on the burden of maintaining the language's
invariants.

Doing something like the above is the moral equivalent of a C
program that sets a floating point variable to some random
value, memcpy'ing the bit representation of the float into an
integer, casting that to a function pointer, and then blaming C
when the program crashes.  Doctor, it hurts when I punch myself
in the face.

If you _do_ need to play shenanigans with passing around
references to hardware or through an FFI, it's your
responsibility to make sure you aren't violating the rules of
the language.  But at least `unsafe` makes it clear where the
violations might be.

>BTW, in a related article at that site, the following Rust CVE was
>disclosed:
>
>https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html
>
>Not the first time I have seen that type of mistake elsewhere. Interesting
>that Rust can have the same problem and that it wasn't detected until now.

That's a logic bug in a system interface; it has nothing to do
with the language aside from being in a library that ships with
the toolchain.

	- Dan C.