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.

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.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.

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.