I think that arises from a punitive view of the role of the compiler/library instead of a transparency view. I want the language to make it simpler to write robust code, not to impose possibly incorrect style rules.
Conversation
Undefinedness of use of invalid pointers is not a "style rule".
2
2
The problem is that, memory protection is only granular down to 4k blocks(usually). So its very easy to be a little wrong and not trigger a crash. These bugs are hard to find. This wouldn't solve the issue but give you more tools.
1
ASan and Valgrind find these for you. Ideally a non-debugging-oriented version of ASan could be used in production, but there are obstacles to making it safe and efficient. The future is almost certainly something like ARM's MTE that does it in hw with 16-byte granularity.
3
MTE is really garbage. The history of processors is littered with similar errors.
1
No, MTE is the first non-garbage thing in this class. The rest are all garbage, yes. MTE was actually designed (or they randomly got it right on the Nth guess) around the software model problem rather than being some hw person's random idea with no correspondence to sw needs.
2
2
Used correctly, MTE completely eliminates all sequential overflow/underflow, completely eliminates attacks that clobber metadata, and provides strong protection (for multiple generations of alloc/free) against UAF.
1
It probably has the same weakness as ASAN: it can't detect overflows between adjacent members within a struct or within an array of structs. Because you can't insert arbitrary padding without breaking the ABI.
3
1
MTE will be available with ARMv8.5. SPARC ADI is the same kind of feature and is available already with software integration for allocators, compilers (stack frame / variable protection), etc. ARMv8.5 MTE uses 16 byte granularity as opposed to SPARC ADI 64 byte granularity.