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