[astrange]

The lack of memory safety is a property of C implementations, not the language itself. You can have an implementation that reliably crashes on memory errors if you want, though it does get easier if you leave out a few features like casting pointers to ints and back.

[cornholio]

There is a multiple decade long history of coaxing a memory safe C embodiment. If it was possible to simply implement memory safety without fundamentally changing the language, you would have a compiler flag that would give to you, requiring no source modifications.

No compiler gives you that memory safety flag (aside from very specific security features, ex. -fstack-protector) because it's not possible in C.

[rini17]

It is totally possible for pointers with bounds checking to exist in C. Turbo C did that 30 years ago. However, why bother trying when whole culture is biased against it and you can use any of the other languages?

[akoboldfrying]

>Turbo C did that 30 years ago.

I used Turbo C++ (not C) back in the day, and recall near pointers, far pointers, based pointers, but I don't recall bounds-checked pointers. Do you remember any details?

>However, why bother trying

Because it would immediately make the large amounts of C code still in the wild safer for the users, who do care?

[rini17]

I remember it as an compiler otion.

[baq]

For the sake of the example let's assume you make a C to Python compiler/transpiler which uses native Python arrays for every stack or heap based allocation and every pointer arithmetic would be replaced by a checked operation, you'd quite likely get a memory safe language in the 'shellcode impossible unless you really set the program up for it' sense.

[astrange]

https://discourse.llvm.org/t/rfc-enforcing-bounds-safety-in-...

You can also run with ASan on, or compile into WebAssembly and run that… obviously not perfect though.