Date: Thu, 5 Sep 2024 16:12:58 -0400 From: Jan Knepper <jan@digitaldaemon.com> To: Dmitry Salychev <dsl@FreeBSD.org>, Karl Denninger <karl@denninger.net> Cc: freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in any system) Message-ID: <00e1d94b-7484-4cc1-97ef-dabf801f65d5@digitaldaemon.com> In-Reply-To: <86bk1150kh.fsf@peasant.bootbsd.com> References: <CAOtMX2iCNX5OkdeghnbmcMrO0UYWwm4zfxFSZGznOznu%2Bmh5rA@mail.gmail.com> <b2c6c38c-4e14-4e3e-b6ac-3f9c13519a0f@denninger.net> <86bk1150kh.fsf@peasant.bootbsd.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format.
--------------tn8atr0Z1Z8NOIGhNObB7LaE
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
On 9/5/24 15:55, Dmitry Salychev wrote:
> Karl Denninger<karl@denninger.net> writes:
>
>> [[PGP Signed Part:Undecided]]
>> On 9/5/2024 14:09, Alan Somers wrote:
>>
>> By now I expect that most of you have seen the long list of new
>> security advisories that just came out. Strikingly, all were the
>> result of memory handling errors. And none of them wouldn't have
>> happened if their respective programs had been written in a
>> memory-safe language.
>>
>> ...
>> Thus for kernel-level or system-library-level code (or for that matter execution-heavy applications) that are executed very
>> frequently and thus imposes said cost all the time (or at least a very large amount of the time) the debate over "do it once and
>> do it right, even if it takes longer and requires programmers of higher skill" approach .vs. "do it fast and let the computer
>> catch and fix the stupidity at runtime, imposing said cost in every instance whether stupidity occurred in the coding or not"
>> should not, in my opinion anyway, end in the latter decision.
> Well said.
>
> Personally, I wouldn't argue that people tend to do stupid thing with
> the tools given, but putting everyone in diapers is just _one_ possible
> way to solve the problem.
>
> If Rust is somehow considered to be brought deep down in the FreeBSD
> kernel, I'd suggest to consider other options, e.g. MISRA C:2023 and
> MISRA C++:2023.
>
Agreed...
And use code analyzers/static analyzers..
I have not worked with Coverity recently, but when we did, it was pretty
good what it found & reported.
We had to convince that the $50K/year or $100K/year price tag, what ever
it was, was worth it because Coverity would do for a price per year what
we could not hire anyone to do for us with the same consistency, speed,
and accuracy.
There are several others.
More and more, these type of tools are being integrated into modern day
compiler tool-chains.
Use them!
--------------tn8atr0Z1Z8NOIGhNObB7LaE
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
On 9/5/24 15:55, Dmitry Salychev wrote:<br>
<blockquote type="cite"
cite="mid:86bk1150kh.fsf@peasant.bootbsd.com">
<pre class="moz-quote-pre" wrap="">
Karl Denninger <a class="moz-txt-link-rfc2396E" href="mailto:karl@denninger.net"><karl@denninger.net></a> writes:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">[[PGP Signed Part:Undecided]]
On 9/5/2024 14:09, Alan Somers wrote:
By now I expect that most of you have seen the long list of new
security advisories that just came out. Strikingly, all were the
result of memory handling errors. And none of them wouldn't have
happened if their respective programs had been written in a
memory-safe language.
...</pre>
</blockquote>
</blockquote>
<blockquote type="cite"
cite="mid:86bk1150kh.fsf@peasant.bootbsd.com">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
Thus for kernel-level or system-library-level code (or for that matter execution-heavy applications) that are executed very
frequently and thus imposes said cost all the time (or at least a very large amount of the time) the debate over "do it once and
do it right, even if it takes longer and requires programmers of higher skill" approach .vs. "do it fast and let the computer
catch and fix the stupidity at runtime, imposing said cost in every instance whether stupidity occurred in the coding or not"
should not, in my opinion anyway, end in the latter decision.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Well said.
Personally, I wouldn't argue that people tend to do stupid thing with
the tools given, but putting everyone in diapers is just _one_ possible
way to solve the problem.
If Rust is somehow considered to be brought deep down in the FreeBSD
kernel, I'd suggest to consider other options, e.g. MISRA C:2023 and
MISRA C++:2023.
</pre>
</blockquote>
Agreed...<br>
<br>
And use code analyzers/static analyzers..<br>
<br>
I have not worked with Coverity recently, but when we did, it was
pretty good what it found & reported.<br>
We had to convince that the $50K/year or $100K/year price tag, what
ever it was, was worth it because Coverity would do for a price per
year what we could not hire anyone to do for us with the same
consistency, speed, and accuracy.<br>
<br>
There are several others.<br>
<br>
More and more, these type of tools are being integrated into modern
day compiler tool-chains.<br>
<br>
Use them!<br>
<br>
<br>
</body>
</html>
--------------tn8atr0Z1Z8NOIGhNObB7LaE--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00e1d94b-7484-4cc1-97ef-dabf801f65d5>