Could we make C arrays memory safe? Probably not, but let's try anyway

Could we? So many languages and libraries have done it.

Should we? Pointer stunts are fun to use.

whaat...c arrays are safe, just make sure to avoid bugs & use cases that make them unsafe! ;P

imo, when safety is required, use a diff language with in grammar options.

https://ziglearn.org/chapter-1/#runtime-safety

I am always baffled that C didn't ever get a native string type. Strings are used in what feels like 99.99999% of the applications written. Having proper strings that don't require fiddling with pointers on bytes would likely prevent more than 50% of security issues out there.

Without system/external libraries C is more like easier to read assembly, without much on top of it. There are no strings as we understand them in assembly, only pointers to sequential lump of RAM where NULL character means end of string. That's why C is so great as language for libraries at the level where strings are only for debugging and a waste of computing time anyway.
But for some reason often instead of writing a library in C and then linking to it in some high level language to handle the operations where strings are common, people try to use the hammer for everything and end up with overflowing buffers or trying to make exceptions in the kernel for D-Bus
- I know that C is meant only as a little step forward from assembler. But it was also fine to introduce arrays (which are also not a thing in asm where you only operate on pointers). So why not also add a datatype for THE ONE THING that is used almost everywhere?
  There are thousands of useful things one could argue about if they would make sense in the language or not (and in the case of C I would be totally fine with saying "no" to all of them). But strings IMO are not just some fringe feature that is used here and there. They are mission critical across the board and far too important to be left for libraries.
You can just write your own implementation it's not too complex or just use a string library.
- I can also write my own programming language. That wasn't the point.
- This is part of the problem. Instead of solid primitives you have to implement them yourself or pull in a library, both of which you have to hope are compatible with other libraries (or you have to convert manually all the time).
  How many people who write their own string implementation do you think do so perfectly? I'd guess at most 50%. This means that basic operations in a good number of apps will have unknown bugs. Fixing bugs in application logic is one thing, but having to debug low-level type implementations is not something the average developer should do.

As language-wide change: this will require additional checks, the first thing embedded developers will ask is "how do we disable it?"
For personal growth: yeah, it's a nice project :)
For production code: why reinvent the wheel? GLib is LGPL

Wouldn't any sort of C++/Java/Rust Array/Vector work for this? You still have the possibility for runtime panics, but you're never going to dereference an invalid memory address with those abstractions.

If the goal is to prevent any sort of runtime error with arrays, I'm thinking you'll have to set some strict boundaries or risk running against the limits of computability.

You're talking about 2 things: 1. Strict aliasing to guarantee nobody does anything stupid with the pointers, and 2. Bounds checking at compile time with runtime checks for anything that cant be guaranteed at compile time.

There are analysis passes that do this, coverity did some, as does gcov though less well.