Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 6 Sep 2024 08:13:34 +0100
From:      David Chisnall <theraven@freebsd.org>
To:        Alan Somers <asomers@freebsd.org>
Cc:        Karl Denninger <karl@denninger.net>, freebsd-hackers@freebsd.org
Subject:   Re: The Case for Rust (in any system)
Message-ID:  <F7C2B30C-D442-4720-B725-B5E03D4A020E@freebsd.org>
In-Reply-To: <CAOtMX2ioxXmQTRNBe9k6yEGi9cBYGNQ1dYjrtjUfWAMyMKEA2g@mail.gmail.com>
References:  <CAOtMX2ioxXmQTRNBe9k6yEGi9cBYGNQ1dYjrtjUfWAMyMKEA2g@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 5 Sep 2024, at 20:50, Alan Somers <asomers@freebsd.org> wrote:
>=20
> I think you are misinformed about the runtime costs involved.  In
> fact, Rust's overhead is quite low.

It=E2=80=99s very hard to get good apples to apples comparisons here but the=
 main thing to remember is that C and Rust compile down to the same instruct=
ion sets. For spatial safety, you have basically two cases:

 - Things where the size is statically known and so all accesses are in boun=
ds if their offsets are known.
 - Things where the size needs to be carried around with the object.

There is nothing magic in C here. You either have fixed-sized things and a c=
ompiler will be able to statically bounds check (though will typically only w=
arn for invalid ones) or you carry the length around and check it. The diffe=
rence is that Rust or C++ can express both of these in the type system and s=
o will always insert bounds checks for any access where they cannot be prove=
n to be redundant.

The cases where you will see a difference are the ones where the safety depe=
nds on some extrinsic property that the programmer knows but which cannot be=
 expressed in the type system. In C, you will do an unchecked access. In Rus=
t, you *can* do unsafe things with raw pointers, but usually you won=E2=80=99=
t, and so you=E2=80=99ll get bounds checks that are redundant. Assuming, of c=
ourse, that the assumption that the programmer made is correct and remains c=
orrect as the code is refactored. Which it often isn=E2=80=99t, and then you=
 get security vulnerabilities.

David




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F7C2B30C-D442-4720-B725-B5E03D4A020E>