www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Safer Linux Kernel Modules Using the D Programming Language

reply Alexandru Militaru <alexandru.cmilitaru gmail.com> writes:
Hi everyone,

If you remember the "D for a  safer Linux Kernel“ talk from DConf 
2019 [1], then you might want to read our paper [2] on that 
matter that was just published in IEEE Access Journal.

There's also an ongoing discussion about it on Hacker News in 
case someone is interested [3].

Cheers,
Alexandru

[1]  https://youtu.be/weRSwbZtKu0
[2] https://ieeexplore.ieee.org/document/9987502
[3] https://news.ycombinator.com/item?id=34260355
Jan 05 2023
next sibling parent reply areYouSureAboutThat <areYouSureAboutThat gmail.com> writes:
On Thursday, 5 January 2023 at 20:24:07 UTC, Alexandru Militaru 
wrote:

 Hi everyone,

 If you remember the "D for a  safer Linux Kernel“ talk from 
 DConf 2019 [1], then you might want to read our paper [2] on 
 that matter that was just published in IEEE Access Journal.

 There's also an ongoing discussion about it on Hacker News in 
 case someone is interested [3].

 Cheers,
 Alexandru

 [1]  https://youtu.be/weRSwbZtKu0
 [2] https://ieeexplore.ieee.org/document/9987502
 [3] https://news.ycombinator.com/item?id=34260355


nice work. and an interesting read. well done for getting it 
published!

btw. Linus one said, more or less, that one reason he likes C so 
much, is because when he is typing it, he can visualise what 
assembly will be produced (i.e. his mind is always intune with 
the code the machine will actually run).

I wonder if he could every say the same about D code though 
(that's a question).
Jan 05 2023
next sibling parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Fri, Jan 06, 2023 at 04:07:12AM +0000, areYouSureAboutThat via
Digitalmars-d-announce wrote:
[...]

 btw. Linus one said, more or less, that one reason he likes C so much, is
 because when he is typing it, he can visualise what assembly will be
 produced (i.e. his mind is always intune with the code the machine will
 actually run).


That has stopped being true for at least a decade or more. C was
designed to map well to the PDP-11's instruction set; modern CPU's are
completely different beasts with out-of-order execution, cache
hierarchy, multi-core, multi-thread per core, expanded instruction sets,
and microcode. Why do you think, for example, that in the kernel
functions and intrinsics are used for certain CPU-specific instructions?
Because nothing in C itself corresponds to them.  The closeness of C to
the CPU is only an illusion.


T

-- 
Don't get stuck in a closet---wear yourself out.
Jan 06 2023
parent reply Tejas <notrealemail gmail.com> writes:
On Friday, 6 January 2023 at 10:29:30 UTC, H. S. Teoh wrote:

 On Fri, Jan 06, 2023 at 04:07:12AM +0000, areYouSureAboutThat 
 via Digitalmars-d-announce wrote: [...]

 btw. Linus one said, more or less, that one reason he likes C 
 so much, is because when he is typing it, he can visualise 
 what assembly will be produced (i.e. his mind is always intune 
 with the code the machine will actually run).


 That has stopped being true for at least a decade or more. C 
 was designed to map well to the PDP-11's instruction set; 
 modern CPU's are completely different beasts with out-of-order 
 execution, cache hierarchy, multi-core, multi-thread per core, 
 expanded instruction sets, and microcode. Why do you think, for 
 example, that in the kernel functions and intrinsics are used 
 for certain CPU-specific instructions? Because nothing in C 
 itself corresponds to them.  The closeness of C to the CPU is 
 only an illusion.


 T


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
Jan 06 2023
parent reply areYouSureAboutThat <areYouSureAboutThat gmail.com> writes:
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.
Jan 07 2023
next sibling parent reply Siarhei Siamashka <siarhei.siamashka gmail.com> writes:
On Saturday, 7 January 2023 at 22:25:30 UTC, areYouSureAboutThat 
wrote:

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


There are attempts to rewrite it in safer programming languages 
;-) Such as https://github.com/Byron/gitoxide

Let's see if the alternative implementations turn out to be good 
enough and allow to eventually retire C at least for this 
particular task. Survival for the fittest.


 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.


Doesn't the D code annotated as ` system` already provide the 
same flexibility and control as C? If not, then what is missing?
Jan 07 2023
parent reply areYouSureAboutThat <areYouSureAboutThat gmail.com> writes:
On Saturday, 7 January 2023 at 23:27:02 UTC, Siarhei Siamashka 
wrote:

 There are attempts to rewrite it in safer programming languages 
 ;-) Such as https://github.com/Byron/gitoxide


I'd love to hear Lord Linus's thought on this.


 Let's see if the alternative implementations turn out to be 
 good enough and allow to eventually retire C at least for this 
 particular task. Survival for the fittest.


Yes, as you say, 'survival of the fittest' also applied in 
programming languages ;-)

That certainly says something about C.


 Doesn't the D code annotated as ` system` already provide the 
 same flexibility and control as C? If not, then what is missing?


What missing, is that 'still' nothing has come close to replacing 
C.

Yes, this paper makes a compelling case to look more closely at D.

But could it replace C?

I don't see that ever happening (in my lifetime).

C is not just a programming language anymore. It's a complete 
(and very diverse) ecosystem.

C 'replacement wannabees', have to compete with both.

The only way I see C being replaced, is if all the C programmers 
retire, or RIP, and don't sufficiently get replaced with new ones.
Jan 07 2023
parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Sunday, 8 January 2023 at 02:15:27 UTC, areYouSureAboutThat 
wrote:

 
 C is not just a programming language anymore. It's a complete 
 (and very diverse) ecosystem.


No progress has been made for decades but that doesn't mean 
progress is impossible. Maybe the academia will take note that 
imperative code with goto, void* and static types are nessary and 
stop making meme language.

The unix stack was fair from prefect and the api of shells and 
stdin/out should be typed and semi graphical, hot take.
Jan 07 2023
parent reply Siarhei Siamashka <siarhei.siamashka gmail.com> writes:
On Sunday, 8 January 2023 at 03:18:27 UTC, monkyyy wrote:

 On Sunday, 8 January 2023 at 02:15:27 UTC, areYouSureAboutThat 
 wrote:

 
 C is not just a programming language anymore. It's a complete 
 (and very diverse) ecosystem.


 No progress has been made for decades but that doesn't mean 
 progress is impossible.


C has a very large and diverse ecosystem exactly thanks to "no 
progress". Each and every compatibility breaking change in the 
language flushes a part of the ecosystem down the toilet.

So the recipe for success is to get most of the things right from 
the very beginning (this is partly based on skill and partly 
based on luck). And then try to avoid breaking changes as much as 
possible. C language is a great example of this.
Jan 07 2023
parent monkyyy <crazymonkyyy gmail.com> writes:
On Sunday, 8 January 2023 at 03:58:43 UTC, Siarhei Siamashka 
wrote:

 On Sunday, 8 January 2023 at 03:18:27 UTC, monkyyy wrote:

 On Sunday, 8 January 2023 at 02:15:27 UTC, areYouSureAboutThat 
 wrote:

 
 C is not just a programming language anymore. It's a complete 
 (and very diverse) ecosystem.


 No progress has been made for decades but that doesn't mean 
 progress is impossible.


 C has a very large and diverse ecosystem exactly thanks to "no 
 progress".


I was referring to all programming languages and computer science
Jan 07 2023
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/7/2023 2:25 PM, areYouSureAboutThat wrote:

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


Yes, as long as you don't make any mistakes. A table saw won't cut your fingers 
off if you never make a mistake, too.



 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.


Buffer overflows are trivial to have in C, and C has no mechanism to prevent 

C code.



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


There's nothing you can do in C that you cannot express in D, with the same
code 
being generated.

Even bitfields!



 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.


Or DasBetterC!
Jan 08 2023
next sibling parent reply Siarhei Siamashka <siarhei.siamashka gmail.com> writes:
On Monday, 9 January 2023 at 03:54:32 UTC, Walter Bright wrote:

 Buffer overflows are trivial to have in C, and C has no 
 mechanism to prevent them.


ASAN, Valgrind, Clang Static Analyzer and plenty of other tools 
are the practical mechanisms to prevent buffer overflows. Yes, 
they are not baked into the ISO language standard. But D has no 
ISO language standard at all.
Jan 08 2023
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 9 January 2023 at 04:31:48 UTC, Siarhei Siamashka 
wrote:

 On Monday, 9 January 2023 at 03:54:32 UTC, Walter Bright wrote:

 Buffer overflows are trivial to have in C, and C has no 
 mechanism to prevent them.


 ASAN, Valgrind, Clang Static Analyzer and plenty of other tools 
 are the practical mechanisms to prevent buffer overflows. Yes, 
 they are not baked into the ISO language standard. But D has no 
 ISO language standard at all.


The best part of memory safe systems programming languages is 
that many of those tools don't even have to exist, they are part 
of language semantics!
Jan 08 2023
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/8/2023 10:34 PM, Paulo Pinto wrote:

 The best part of memory safe systems programming languages is that many of
those 
 tools don't even have to exist, they are part of language semantics!


Exactly! I once annoyed the Coverity folks by telling them that my goal with D 
was to make Coverity irrelevant.
Jan 08 2023
prev sibling parent reply Siarhei Siamashka <siarhei.siamashka gmail.com> writes:
On Monday, 9 January 2023 at 06:34:23 UTC, Paulo Pinto wrote:

 On Monday, 9 January 2023 at 04:31:48 UTC, Siarhei Siamashka

 ASAN, Valgrind, Clang Static Analyzer and plenty of other 
 tools are the practical mechanisms to prevent buffer 
 overflows. Yes, they are not baked into the ISO language 
 standard. But D has no ISO language standard at all.


 The best part of memory safe systems programming languages is 
 that many of those tools don't even have to exist, they are 
 part of language semantics!


Memory safe systems programming language is an oxymoron. To be 
suitable for systems programming, the language has to provide a 
mechanism to opt out of safety at least for some parts of the 
code. These parts of code may have memory safety bugs. The 
compiler of the safe language itself may have bugs. Valgrind is 
very useful for troubleshooting D issues and this usefulness 
won't go away any time soon. Here's one example: 
https://forum.dlang.org/post/msjrcymphcdquslfgbrn forum.dlang.org
Jan 08 2023
parent Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 9 January 2023 at 07:23:48 UTC, Siarhei Siamashka 
wrote:

 On Monday, 9 January 2023 at 06:34:23 UTC, Paulo Pinto wrote:

 On Monday, 9 January 2023 at 04:31:48 UTC, Siarhei Siamashka

 ASAN, Valgrind, Clang Static Analyzer and plenty of other 
 tools are the practical mechanisms to prevent buffer 
 overflows. Yes, they are not baked into the ISO language 
 standard. But D has no ISO language standard at all.


 The best part of memory safe systems programming languages is 
 that many of those tools don't even have to exist, they are 
 part of language semantics!


 Memory safe systems programming language is an oxymoron. To be 
 suitable for systems programming, the language has to provide a 
 mechanism to opt out of safety at least for some parts of the 
 code. These parts of code may have memory safety bugs. The 
 compiler of the safe language itself may have bugs. Valgrind is 
 very useful for troubleshooting D issues and this usefulness 
 won't go away any time soon. Here's one example: 
 https://forum.dlang.org/post/msjrcymphcdquslfgbrn forum.dlang.org


It is a big difference having to audit 100% of the source code 
like in C, or just 1%.

One of the reasons why Burroughs is still available as Unisys 
ClearPath MCP, is that a couple of agencies that care about 
secure servers above anything else are willing to keep paying for 
it, alongside the safety guarantes provided by NEWP.
Jan 09 2023
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/8/2023 8:31 PM, Siarhei Siamashka wrote:

 On Monday, 9 January 2023 at 03:54:32 UTC, Walter Bright wrote:

 Buffer overflows are trivial to have in C, and C has no mechanism to prevent 
 them.


 
 ASAN, Valgrind, Clang Static Analyzer and plenty of other tools are the 
 practical mechanisms to prevent buffer overflows.



code. 
Valgrind, etc., only detect overflow if there's a test case that causes 
overflow. That's why it's not as good as static checks.

Clang Static analyzer can only detect a small subset of buffer overflows.



 Yes, they are not baked into the ISO language standard.


They can't be because the C semantics make it impossible.



 But D has no ISO language standard at all.


Neither does Rust.

D can do everything C can. And more. Valgrind works with D code, too.
Jan 08 2023
parent reply Siarhei Siamashka <siarhei.siamashka gmail.com> writes:
On Monday, 9 January 2023 at 07:15:43 UTC, Walter Bright wrote:

 On 1/8/2023 8:31 PM, Siarhei Siamashka wrote:

 Yes, they are not baked into the ISO language standard.


 They can't be because the C semantics make it impossible.


It's impractical to have this in the ISO standard, but surely not 
impossible. Various C compilers from different vendors implement 
bounds checking. See:

   * https://bellard.org/tcc/tcc-doc.html#Bounds
   * 
https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html
   * https://clang.llvm.org/docs/AddressSanitizer.html
   * 
https://learn.microsoft.com/en-us/visualstudio/debugger/how-to-use-native-run-time-checks?view=vs-2022

So your statement that "C has no mechanism to prevent them" just 
ignores reality and the existing C compilers. If you are 
comparing the lowest common denominator ISO C spec with the 
vendor specific DigitalMars D implementation, then this is not a 
honest apples-to-apples comparison.

The Linux kernel is using GNU C compiler and recently switched 
from `-std=gnu89` to `-std=gnu11`.

Bounds checking in the Linux kernel is done by 
https://docs.kernel.org/dev-tools/kfence.html or 
https://docs.kernel.org/dev-tools/kasan.html


 But D has no ISO language standard at all.


 Neither does Rust.


Too bad for Rust. Though they do have language editions and 
there's the Ferrocene project too.
Jan 10 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/10/2023 10:49 PM, Siarhei Siamashka wrote:

 It's impractical to have this in the ISO standard, but surely not impossible. 
 Various C compilers from different vendors implement bounds checking. See:
 
    * https://bellard.org/tcc/tcc-doc.html#Bounds


This works by constructing a data structure of all the allocated memory, and 
then comparing a pointer dereference to see if it's pointing to valid data. It 
sounds like what valgrind does. It's very slow, and wouldn't be used in a 
shipped executable, like you wouldn't ship valgrind. It's vulnerable to memory 
corruption when your app gets tested with inputs that were never tested when 
this checking was turned on.



    * https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html


Adds a bunch of runtime checks you wouldn't want to ship an executable with
them 
turned on.


    * https://clang.llvm.org/docs/AddressSanitizer.html


Same problem. 2x slowdown, won't use it in shipped executable.


    * 
 https://learn.microsoft.com/en-us/visualstudio/debugger/how-to-use-native-run-time-checks?view=vs-2022


Not really clear what this does.



 So your statement that "C has no mechanism to prevent them" just ignores
reality 
 and the existing C compilers. If you are comparing the lowest common
denominator 
 ISO C spec with the vendor specific DigitalMars D implementation, then this is 
 not a honest apples-to-apples comparison.


They all seem to have the same problem - they are only useful when the program 
is under test. When the program is shipped, they're not there.


 The Linux kernel is using GNU C compiler and recently switched from
`-std=gnu89` 
 to `-std=gnu11`.
 
 Bounds checking in the Linux kernel is done by 
 https://docs.kernel.org/dev-tools/kfence.html or


Being sampling based, this is not good enough.



 https://docs.kernel.org/dev-tools/kasan.html


Another test-only tool.

Please don't misunderstand me, these tools are good. But they have really 
nothing to do with the C language specification (which is completely unhelpful 
in resolving this issue), have too high overhead to be useful in a shipped 

in 
shipped software.

I stand by the idea that C's semantics make it impossible. These tools are all 
things layered on top of C, and they certainly help, and I would use them if I 
was developing in C, but they simply do not solve the problem.
Jan 11 2023
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
By the way, back in the 80's, I wrote my own pointer checker for my own use 
developing C code. It was immensely useful in flushing bugs out of my code. 
There are vestiges of it still in the dmd source code.

But it ran very ssssslllllooooooowwwwwwlllllyyyyy, and was not usable for 
shipped code.

A lot of very capable engineers have working on this problem C has for many 
decades. If it was solvable, they would have solved it by now.
Jan 11 2023
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Wednesday, 11 January 2023 at 09:52:23 UTC, Walter Bright 
wrote:

 By the way, back in the 80's, I wrote my own pointer checker 
 for my own use developing C code. It was immensely useful in 
 flushing bugs out of my code. There are vestiges of it still in 
 the dmd source code.

 But it ran very ssssslllllooooooowwwwwwlllllyyyyy, and was not 
 usable for shipped code.

 A lot of very capable engineers have working on this problem C 
 has for many decades. If it was solvable, they would have 
 solved it by now.


It is kind of "solved", by turning all computers into C machines,

Solaris under SPARC ADI,

https://docs.oracle.com/cd/E53394_01/html/E54815/gqajs.html

Android with MTE,

https://source.android.com/docs/security/test/memory-safety/arm-mte

iOS with XP,

https://developer.apple.com/documentation/security/preparing_your_app_to_work_with_pointer_authentication

FreeBSD with CHERI,

https://www.cheribsd.org/

Intel messed up their MPX design, but certainly won't want to be 
left behind.

Basically acknowledging that only having bounds and pointer 
checking via hardware memory tagging will fix C derived issues, 
and all mitigations thus far have failed one way or the other.
Jan 11 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/11/2023 3:26 AM, Paulo Pinto wrote:

 It is kind of "solved", by turning all computers into C machines,


What an amazing amount of work just to avoid adding dynamic arrays to C.
Jan 11 2023
parent reply Tejas <notrealemail gmail.com> writes:
On Wednesday, 11 January 2023 at 19:27:15 UTC, Walter Bright 
wrote:

 On 1/11/2023 3:26 AM, Paulo Pinto wrote:

 It is kind of "solved", by turning all computers into C 
 machines,


 What an amazing amount of work just to avoid adding dynamic 
 arrays to C.


Well, the companies don't get to single-handedly decide what 
features to add or deprecate, thanks to C spec being written by 
ISO, which is why they have developed their own PLs.

But also, adding dynamic arrays to C won't make the currently 
existing C code safer, the one they care about, because no one's 
gonna send the money to update their C89/99/whatever code to 
C23/26. Even if they did, there's no guarantee others would as 
well.

So when you can't change the world, what do you do?

You change yourself, and that's what they did, by making bounds 
checking and whatnot part of the _hardware semantics_ itself, now 
the C programmers get to be happy that the program still is 2 
instructions long, while at the micro-architecture/microcode 
level the checks are still getting performed.
Jan 11 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/11/2023 8:15 PM, Tejas wrote:

 Well, the companies don't get to single-handedly decide what features to add
or 
 deprecate, thanks to C spec being written by ISO, which is why they have 
 developed their own PLs.


Yes they can, as they add extensions to C all the time.



 But also, adding dynamic arrays to C won't make the currently existing C code 
 safer, the one they care about, because no one's gonna send the money to
update 
 their C89/99/whatever code to C23/26. Even if they did, there's no guarantee 
 others would as well.


You can incrementally fix code, as I do with the dmd source code (originally in 
C) regularly.
Jan 11 2023
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 1/12/23 07:25, Walter Bright wrote:

 

 But also, adding dynamic arrays to C won't make the currently existing 
 C code safer, the one they care about, because no one's gonna send the 
 money to update their C89/99/whatever code to C23/26. Even if they 
 did, there's no guarantee others would as well.


 
 You can incrementally fix code, as I do with the dmd source code 
 (originally in C) regularly.


Yes; _source code_. This is the crux of the matter. Can't incrementally 
fix source code that you don't have access to.
Jan 16 2023
prev sibling parent Siarhei Siamashka <siarhei.siamashka gmail.com> writes:
On Wednesday, 11 January 2023 at 09:44:27 UTC, Walter Bright 
wrote:

 Bounds checking in the Linux kernel is done by 
 https://docs.kernel.org/dev-tools/kfence.html or


 Being sampling based, this is not good enough.


I disagree. KFENCE is actually a perfect fit for what is needed 
for the Linux kernel. LTS kernel releases are maintained for many 
years and keep getting bugfixes. They also have a large userbase. 
It means that after a year or so, most of the bugs of this kind 
can be caught and fixed. All of this with near zero performance 
overhead.

The reactive nature of this approach and also reliance on the 
"safety in numbers" idea works best for slowly evolving popular 
software. But I agree that it won't be good enough for a rapidly 
evolving unpopular application. Or when the cost of encountering 
a bug on the end user system is way too high.


 Please don't misunderstand me, these tools are good. But they 
 have really nothing to do with the C language specification


They have everything to do with the C language specification, 
because they improve memory safety specifically for C language.


 (which is completely unhelpful in resolving this issue), have 
 too high overhead to be useful in a shipped product,


They are extremely effective and widely used in practice for 
developing any modern software in C language.


 and have not stopped C from having buffer overflows being the 



They surely prevented and/or allowed to debug and fix a large 

actually backed by anything? The statistics from Chromium seems 
to disagree and there are also a lot of problems on the list even 
not related to memory safety: 
https://forum.dlang.org/post/mailman.2828.1670270281.31357.digitalmars-d puremagic.com


 I stand by the idea that C's semantics make it impossible. 
 These tools are all things layered on top of C, and they 
 certainly help, and I would use them if I was developing in C, 
 but they simply do not solve the problem.


They only partially solve the problem and they surely have 
tradeoffs. Just like D also only partially solves the memory 
safety problem and has its own tradeoffs. A honest comparison 
needs to take this into account and then you will probably see 
why D does not look like a perfect solution. And why Rust is 
eating D's lunch.
Jan 12 2023
prev sibling parent reply areYouSureAboutThat <areYouSureAboutThat gmail.com> writes:
On Monday, 9 January 2023 at 03:54:32 UTC, Walter Bright wrote:

 Yes, as long as you don't make any mistakes. A table saw won't 
 cut your fingers off if you never make a mistake, too.


And yet, people keep using them (table saws).

Don't underestimate the level of risk humans are happily willing 
to accept, in exchange for some personal benefit.
Jan 09 2023
parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Monday, 9 January 2023 at 09:08:59 UTC, areYouSureAboutThat 
wrote:

 On Monday, 9 January 2023 at 03:54:32 UTC, Walter Bright wrote:

 Yes, as long as you don't make any mistakes. A table saw won't 
 cut your fingers off if you never make a mistake, too.


 And yet, people keep using them (table saws).

 Don't underestimate the level of risk humans are happily 
 willing to accept, in exchange for some personal benefit.


and people literally kill themselves by overestimating their 
skills
https://youtu.be/wzosDKcXQ0I?t=441
Jan 09 2023
parent reply areYouSureAboutThat <areYouSureAboutThat gmail.com> writes:
On Monday, 9 January 2023 at 11:04:24 UTC, Patrick Schluter wrote:

 On Monday, 9 January 2023 at 09:08:59 UTC, areYouSureAboutThat 
 wrote:

 On Monday, 9 January 2023 at 03:54:32 UTC, Walter Bright wrote:

 Yes, as long as you don't make any mistakes. A table saw 
 won't cut your fingers off if you never make a mistake, too.


 And yet, people keep using them (table saws).

 Don't underestimate the level of risk humans are happily 
 willing to accept, in exchange for some personal benefit.


 and people literally kill themselves by overestimating their 
 skills
 https://youtu.be/wzosDKcXQ0I?t=441


Wood is a conductor? I never knew that.

And yet,  safe is still not the default ;-)
Jan 09 2023
parent Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 9 January 2023 at 20:07:01 UTC, areYouSureAboutThat 
wrote:

 On Monday, 9 January 2023 at 11:04:24 UTC, Patrick Schluter 
 wrote:

 On Monday, 9 January 2023 at 09:08:59 UTC, areYouSureAboutThat 
 wrote:

 On Monday, 9 January 2023 at 03:54:32 UTC, Walter Bright 
 wrote:

 Yes, as long as you don't make any mistakes. A table saw 
 won't cut your fingers off if you never make a mistake, too.


 And yet, people keep using them (table saws).

 Don't underestimate the level of risk humans are happily 
 willing to accept, in exchange for some personal benefit.


 and people literally kill themselves by overestimating their 
 skills
 https://youtu.be/wzosDKcXQ0I?t=441


 Wood is a conductor? I never knew that.

 And yet,  safe is still not the default ;-)


Because the DIP to make it default considered calling extern C 
code as "safe", thus voiding its guarantees.
Jan 09 2023
prev sibling parent areYouSureAboutThat <areYouSureAboutThat gmail.com> writes:
On Friday, 6 January 2023 at 04:07:12 UTC, areYouSureAboutThat 
wrote:

 btw. Linus one said, more or less, that one reason he likes C 
 so much, is because when he is typing it, he can visualise what 
 assembly will be produced (i.e. his mind is always intune with 
 the code the machine will actually run).

 I wonder if he could every say the same about D code though 
 (that's a question).


btw. Just in case I misquoted him, I found the link:

https://www.youtube.com/watch?v=CYvJPra7Ebk
Jan 06 2023
prev sibling next sibling parent thebluepandabear <therealbluepandabear protonmail.com> writes:
On Thursday, 5 January 2023 at 20:24:07 UTC, Alexandru Militaru 
wrote:

 Hi everyone,

 If you remember the "D for a  safer Linux Kernel“ talk from 
 DConf 2019 [1], then you might want to read our paper [2] on 
 that matter that was just published in IEEE Access Journal.

 There's also an ongoing discussion about it on Hacker News in 
 case someone is interested [3].

 Cheers,
 Alexandru

 [1]  https://youtu.be/weRSwbZtKu0
 [2] https://ieeexplore.ieee.org/document/9987502
 [3] https://news.ycombinator.com/item?id=34260355


interesting...

thanks, hopefully D will make it into the Linux kernel sometime 
in the future

let's try to get Linus' attention !
Jan 05 2023
prev sibling parent Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Thursday, 5 January 2023 at 20:24:07 UTC, Alexandru Militaru 
wrote:

 Hi everyone,

 If you remember the "D for a  safer Linux Kernel“ talk from 
 DConf 2019 [1], then you might want to read our paper [2] on 
 that matter that was just published in IEEE Access Journal.



 [1]  https://youtu.be/weRSwbZtKu0
 [2] https://ieeexplore.ieee.org/document/9987502


Kudos to you for staying on the ball on this topic. I enjoyed 
your talk back then and this article adds credibility to this 
important application of the language and addresses a wider 
audience. Well done.

Bastiaan.
Jan 07 2023