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

[Bill Gunshannon]

On 4/5/22 14:55, Dan Cross wrote:
> In article <t2i0e4$lpu$5 at dont-email.me>,
> Simon Clubley  <clubley at remove_me.eisner.decus.org-Earth.UFP> wrote:
>> On 2022-04-05, Dan Cross <cross at spitfire.i.gajendra.net> wrote:
>>> In article <jb2t2oF49voU1 at mid.individual.net>,
>>> Bill Gunshannon  <bill.gunshannon at gmail.com> wrote:
>>>> So, I have been following this discussion for some time now.  I have
>>>> never used Rust.  I have never even looked at Rust. But I do have one
>>>> question.
>>>>
>>>> Just what is it that Rust can do that none of the already existing
>>>> languages could do?
>>>
>>> There are three main interacting features that are unique in
>>> their combination in the language that Rust brings to bear:
>>>
>>> 1) Lifetimes attached to pointers are a first-class primitive in
>>>     the language.  They are literally part of the type.
>>>     References cannot outlive the objects they refer to.
>>> 2) A compile-time borrow checker that ensures that either a
>>>     single mutable reference to an object, or one or more
>>>     immutable references.  In safe rust code, data races are
>>>     impossible.
>>> 3) Object ownership is a first-class primitive in the language,
>>>     and every object has exactly one owner.  All objects must be
>>>     initialized before use.  Dangling pointers and uninitialized
>>>     pointers are
>>>
>>> The combination of these things is incredibly powerful, and
>>> gives you type and memory safety _without garbage collection_.
>>> The result is that you program as if you were using a managed
>>> language, but with explicit control over memory allocation.
>>>
>>> You can even do this on bare metal.  The langauge gives you a
>>> high degree of abstraction with the "core" library, even in
>>> kernel mode.  In that context, it's actually quite pleasant to
>>> use.
>>
>> Do you have any comments on the following Rust CVEs ?
> 
> Sure.
> 
>> It looks like Rust has come up with rather unique ways to screw up:
>>
>> https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust
> 
> These mostly seem to be misuses of FFI interfaces, where the
> bugs are the interface between Rust and foreign code, which is
> necessarily unsafe.
> 
> Rust provides an "escape hatch" from some of the rules of the
> language called, "unsafe" mode.  In unsafe mode, you have access
> to a superset of the language where you can do things you cannot
> do in the safe subset (for example, one can dereference raw
> pointers, or transmute between types).  In unsafe code, the
> burden to maintain the langauge's invariants shift from the
> compiler to the programmer.  What's interesting about this CVE
> list is that that many of the bugs are in unsafe code.
> 
>> Take this one (which I picked at random) for example:
>>
>> https://rustsec.org/advisories/RUSTSEC-2020-0148.html
> 
> Hmm, that's a third-party package using unsafe code.
> 
>> Or this one (which is a nice good old fashioned out of bounds memory access):
>>
>> https://rustsec.org/advisories/RUSTSEC-2020-0039.html
> 
> That's a third-party package using unsafe code.
> 
>> How do they fit into what you say above ?
> 
> I don't think it has much to do with what I said above at all,
> frankly.  I never said that the language was a panacea that
> prevents _all_ bugs.  But it significantly raises the bar over
> just about everything else out there.

And then provides a way to override all the safeties because sometimes
you just need to get the job done.  By the way, for the few remaining
Ada advocates out there, Ada did the same thing with allowing safeties
to be turned off so you could write "unsafe" but functional code.  So
did most versions of Pascal.  C just doesn't make you turn the safeties
on and off.

bill