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
#1 bug in shipped software.
They surely prevented and/or allowed to debug and fix a large
number of buffer overflows. Is your claim about the #1 bug
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.digitalmar...@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.
