No, I haven't kept track of the reports I've seen. They all had array bounds as the #1 error encountered in shipped code.

Edit: I just googled "causes of memory safety bugs in C++". Number 1 answer: "Buffer Overflows/Out-of-Bounds Access"

"Undefined behavior in C/C++ code leads to security flaws like buffer overflows" https://www.trust-in-soft.com/resources/blogs/memory-safety-...

"Some common types of memory safety bugs include: Buffer overflows" https://www.code-intelligence.com/blog/memory_safety_corrupt...

"Memory Safety Vulnerabilities 3.1. Buffer overflow vulnerabilities We’ll start our discussion of vulnerabilities with one of the most common types of errors — buffer overflow (also called buffer overrun) vulnerabilities. Buffer overflow vulnerabilities are a particular risk in C, and since C is an especially widely used systems programming language, you might not be surprised to hear that buffer overflows are one of the most pervasive kind of implementation flaws around." https://textbook.cs161.org/memory-safety/vulnerabilities.htm...

▲

Voultapher 2 days ago | parent [-]

Spatial safety can be achieved exhaustively with a single compiler switch - in clang - and a minor performance hit. Temporal safety is much harder and requires software redesign, that's why it still remains in projects that care about memory-safety and try over a long time to weed out all instances of UB, i.e. critical software like curl, Linux and Chromium.

Temporal safety is usually also much harder to reason about for humans, since it requires more context.

▲

IshKebab 2 days ago | parent [-]

What flag is that? Address sanitizer has a 2x performance hit so presumably not that?

	▲	Voultapher 2 days ago \| parent [-]
		-fbounds-safety [1] Based on their slides [2]. I was wrongly informed one does need to do some light annotation in function signatures and struct definitions for anything ABI relevant. Based on their slides: Ptrdist and Olden benchmark suites - LOC changes: 2.7% (0.2% used unsafe constructs) Much lower than prior approaches - Compile-time overhead: 11% - Code-size (text section) overhead: 9.1% (ranged -1.4% to 38%) - Run-time overhead: 5.1% (ranged -1% to 29%) Measurement on iOS - 0-8% binary size increase per project - No measurable performance or power impact on boot, app launch - Minor overall performance impact on audio decoding/encoding (1%) [1] https://clang.llvm.org/docs/BoundsSafety.html [2] https://llvm.org/devmtg/2023-05/slides/TechnicalTalks-May11/...