News for hackers. Stuff that matters.

A comment on "No way to prevent this" say users of only language where this regularly happens. Parent comment

Re:"No way to prevent this" say users of only language where... by astrange on Wednesday May 22, 2024 @03:54AM (#40438418)
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.
[ Parent | on HN ]
Re:"No way to prevent this" say users of only language where... by cornholio on Wednesday May 22, 2024 @04:10AM (#40438528)
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.

[ Parent | on HN ]
Re:"No way to prevent this" say users of only language where... by rini17 on Wednesday May 22, 2024 @04:33AM (#40438705)
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?
[ Parent | on HN ]
Re:"No way to prevent this" say users of only language where... by akoboldfrying on Wednesday May 22, 2024 @05:05AM (#40438917)
>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?

[ Parent | on HN ]
Re:"No way to prevent this" say users of only language where... by rini17 on Wednesday May 22, 2024 @01:05PM (#40443355)
I remember it as an compiler otion.
[ Parent | on HN ]
Re:"No way to prevent this" say users of only language where... by baq on Wednesday May 22, 2024 @05:04AM (#40438910)
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.
[ Parent | on HN ]
Re:"No way to prevent this" say users of only language where... by astrange on Wednesday May 22, 2024 @03:15PM (#40444991)
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.

[ Parent | on HN ]