digitalmars.D.announce - Safer Linux Kernel Modules Using the D Programming Language
- Alexandru Militaru (11/11) Jan 05 Hi everyone,
- areYouSureAboutThat (10/21) Jan 05 nice work. and an interesting read. well done for getting it
- H. S. Teoh (13/17) Jan 06 That has stopped being true for at least a decade or more. C was
- Tejas (8/24) Jan 06 Those statements, even if spoken recently, are just a way of
- areYouSureAboutThat (26/33) Jan 07 Well, the worlds most widely used source code revision control
- Siarhei Siamashka (9/15) Jan 07 There are attempts to rewrite it in safer programming languages
- areYouSureAboutThat (16/23) Jan 07 I'd love to hear Lord Linus's thought on this.
- monkyyy (8/11) Jan 07 No progress has been made for decades but that doesn't mean
- Siarhei Siamashka (8/15) Jan 07 C has a very large and diverse ecosystem exactly thanks to "no
- monkyyy (3/14) Jan 07 I was referring to all programming languages and computer science
- Walter Bright (10/21) Jan 08 Yes, as long as you don't make any mistakes. A table saw won't cut your ...
- Siarhei Siamashka (5/7) Jan 08 ASAN, Valgrind, Clang Static Analyzer and plenty of other tools
- Paulo Pinto (5/12) Jan 08 The best part of memory safe systems programming languages is
- Walter Bright (3/5) Jan 08 Exactly! I once annoyed the Coverity folks by telling them that my goal ...
- Siarhei Siamashka (9/17) Jan 08 Memory safe systems programming language is an oxymoron. To be
- Paulo Pinto (8/26) Jan 09 It is a big difference having to audit 100% of the source code
- Walter Bright (8/16) Jan 08 And yet C buffer overflows are consistently the #1 problem in production...
- Siarhei Siamashka (22/27) Jan 10 It's impractical to have this in the ISO standard, but surely not
- Walter Bright (23/41) Jan 11 This works by constructing a data structure of all the allocated memory,...
- Walter Bright (7/7) Jan 11 By the way, back in the 80's, I wrote my own pointer checker for my own ...
- Paulo Pinto (16/25) Jan 11 It is kind of "solved", by turning all computers into C machines,
- Walter Bright (2/3) Jan 11 What an amazing amount of work just to avoid adding dynamic arrays to C.
- Tejas (16/21) Jan 11 Well, the companies don't get to single-handedly decide what
- Walter Bright (4/11) Jan 11 You can incrementally fix code, as I do with the dmd source code (origin...
- Timon Gehr (3/11) Jan 16 Yes; _source code_. This is the crux of the matter. Can't incrementally
- Siarhei Siamashka (29/42) Jan 12 I disagree. KFENCE is actually a perfect fit for what is needed
- areYouSureAboutThat (4/6) Jan 09 And yet, people keep using them (table saws).
- Patrick Schluter (5/13) Jan 09 and people literally kill themselves by overestimating their
- areYouSureAboutThat (3/18) Jan 09 Wood is a conductor? I never knew that.
- Paulo Pinto (4/25) Jan 09 Because the DIP to make it default considered calling extern C
- areYouSureAboutThat (4/10) Jan 06 btw. Just in case I misquoted him, I found the link:
- thebluepandabear (6/17) Jan 05 interesting...
- Bastiaan Veelo (7/13) Jan 07 Kudos to you for staying on the ball on this topic. I enjoyed
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
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=34260355nice 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
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
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: [...]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, IMObtw. 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
Jan 06
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, IMOWell, 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
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
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/gitoxideI'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
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
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 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.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.
Jan 07
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:I was referring to all programming languages and computer scienceOn Sunday, 8 January 2023 at 02:15:27 UTC, areYouSureAboutThat wrote:C has a very large and diverse ecosystem exactly thanks to "no progress".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.
Jan 07
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
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
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: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!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
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
On Monday, 9 January 2023 at 06:34:23 UTC, Paulo Pinto wrote:On Monday, 9 January 2023 at 04:31:48 UTC, Siarhei SiamashkaMemory 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.orgASAN, 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
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: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.On Monday, 9 January 2023 at 04:31:48 UTC, Siarhei SiamashkaMemory 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.orgASAN, 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 09
On 1/8/2023 8:31 PM, Siarhei Siamashka wrote:On Monday, 9 January 2023 at 03:54:32 UTC, Walter Bright wrote: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.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.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
On Monday, 9 January 2023 at 07:15:43 UTC, Walter Bright wrote:On 1/8/2023 8:31 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 * 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.htmlYes, they are not baked into the ISO language standard.They can't be because the C semantics make it impossible.Too bad for Rust. Though they do have language editions and there's the Ferrocene project too.But D has no ISO language standard at all.Neither does Rust.
Jan 10
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#BoundsThis 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.htmlAdds a bunch of runtime checks you wouldn't want to ship an executable with them turned on.* https://clang.llvm.org/docs/AddressSanitizer.htmlSame 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-2022Not 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 orBeing sampling based, this is not good enough.https://docs.kernel.org/dev-tools/kasan.htmlAnother 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
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
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
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
On Wednesday, 11 January 2023 at 19:27:15 UTC, Walter Bright wrote:On 1/11/2023 3:26 AM, Paulo Pinto 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. 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.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
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
On 1/12/23 07:25, Walter Bright wrote:Yes; _source code_. This is the crux of the matter. Can't incrementally fix source code that you don't have access to.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 16
On Wednesday, 11 January 2023 at 09:44:27 UTC, Walter Bright wrote: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.Bounds checking in the Linux kernel is done by https://docs.kernel.org/dev-tools/kfence.html orBeing sampling based, this is not good enough.Please don't misunderstand me, these tools are good. But they have really nothing to do with the C language specificationThey 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 theThey 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.comI 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
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
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:and people literally kill themselves by overestimating their skills https://youtu.be/wzosDKcXQ0I?t=441Yes, 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
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:Wood is a conductor? I never knew that. And yet, safe is still not the default ;-)On Monday, 9 January 2023 at 03:54:32 UTC, Walter Bright wrote:and people literally kill themselves by overestimating their skills https://youtu.be/wzosDKcXQ0I?t=441Yes, 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
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:Because the DIP to make it default considered calling extern C code as "safe", thus voiding its guarantees.On Monday, 9 January 2023 at 09:08:59 UTC, areYouSureAboutThat wrote:Wood is a conductor? I never knew that. And yet, safe is still not the default ;-)On Monday, 9 January 2023 at 03:54:32 UTC, Walter Bright wrote:and people literally kill themselves by overestimating their skills https://youtu.be/wzosDKcXQ0I?t=441Yes, 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
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
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=34260355interesting... thanks, hopefully D will make it into the Linux kernel sometime in the future let's try to get Linus' attention !
Jan 05
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/9987502Kudos 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