Safer Linux Kernel Modules Using the D Programming Language

areYouSureAboutThat areYouSureAboutThat at gmail.com
Sat Jan 7 22:25:30 UTC 2023


On Friday, 6 January 2023 at 11:02:03 UTC, Tejas wrote:
>
> Those statements, even if spoken recently, are just a way of 
> maintaining PR. Elon also similarly calls C++ a bloated mess 
> and that all high performance code at Tesla is in C, as if 
> that's something to be proud of... their ultra safety critical 
> software project being built using a very much 
> unsafe-by-defualt-for-everything language...
>
>
> Nvidia made a good decision to use ADA/SPARK, IMO

Well, the worlds most widely used source code revision control 
system, is written in C ;-)

The C language is not the problem, and I'm unable to accept the 
assertion in the paper, that 'C was designed to allow unsafe 
memory operations'. That is a red herring.

In fact, C can be used in a perfectly memory safe manner.

The problem is that too few programmers know how to do that, and 
even very experienced C programmers can get it wrong sometimes. 
Both tools and compilers have come along way over the last 
decade, and it's getting increasingly 'harder' to write memory 
unsafe C, but in the end, in C, its the programmer that has the 
control.

That is  what the paper should have asserted instead of that red 
herring.

What the paper is really asserting, is that this control needs to 
be taken away (at least to some point) from the programmer.

But C will always be the language that gives the programmer the 
flexibilty and control needed, when all the other languages will 
not.

Other languages often claim to be 'C like', but that's mostly 
syntax related.

To be 'C like', the language needs to provide the same 
flexibility and control as C, and map to the hardware and its 
instructions set as well as C. In other words, it's going to end 
up being C anyway.



More information about the Digitalmars-d-announce mailing list