Re: The Case for Rust (in any system)

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!