[WalterBright]

That's why DasBetterC has done very well! You could call it C with array bounds checking.

I occasionally look at statistics on the sources of bugs and security problems in released software. Array bounds overflows far and away are the top cause.

Why aren't people just sick of array overflows? In the latest C and C++ versions, all kinds of new features are trumpeted, but again no progress on array overflows.

I can confidently say that in the 2 decades of D in production use, the incidence of array overflows has dropped to essentially zero. (To trigger a runtime array overflow, you have to write @system code and throw a compiler switch.)

The solution for C I proposed is backwards compatible, and does not make existing code slower.

It would be the greatest feature added to C, singularly worth more than all the other stuff in C23.

[pjmlp]

I don't even understand how the flip from having C++ collection frameworks being bounds checked by default (Turbo Vision, BIDS, OWL, MFC, Powerplant,...) ended happing, with C++98 getting a standard library that does exactly the opposite by default, and a strong cultural resistance on WG21 to change it until goverments started talking about security liabilities and what programming languages to accept in public projects.

As for WG14, I have no hope, they ignored several proposals, and seem keen in having C being as safe as hand writing Assembly code, and even then, Assembly tends to be safer, as UB only happens when doing something the CPU did not expect, macro assemblers don't do clever optimizations.

[kragen]

i think what happened was that turbo vision, owl, mfc, etc., were mostly for line of business applications: work order tracking, mail merge databases, hotel reservations, inventory management, whatever. but since the late 90s those have moved to visual basic, perl, java, microsoft java, python, and js. only the people who really needed c++'s performance (and predictable memory footprint) kept using c++, and similarly for c

maybe as the center of gravity moves from people writing game engines and kernels to people keeping legacy code running we will get more of a constituency for bounds checking

agreed about asm being safer

[pkphilip]

Wow, you mentioned Turbo Vision, OWL etc.. what a blast from the past! had fun developing applications using them

[bakul]

> The solution for C I proposed is backwards compatible, and does not make existing code slower.

Where can I read about it? The only way to make ptrs to array elements also safe that I can think of, is to replace them with triples: (base, element ptr, limit).

[WalterBright]

https://www.digitalmars.com/articles/C-biggest-mistake.html

[bakul]

Thanks. I got interested in this topic as people are talking about writing OS kernel code in Rust but a) it only helps new code and b) very hard to justify rewriting millions of lines of C code in Rust (plus rewrites are never 100% faithful feature wise). If on the other hand if C can be made safer, may be through a stepwise process where the code is rewritten incrementally to pass through C->C0->C1->Cn compilers, each making incremental language changes, much more of code can be made safer. It will never be as good as Rust but I do think this space is worth exploring.

[uecker]

I would much prefer a safe C to Rust.

[actionfromafar]

I don’t always agree but I’ll join you on this particular hill!