Safe C++ proposal is not being continued

Re:Safe C++ proposal is not being continued by Voultapher on Sunday September 14, 2025 @04:05AM (#45238319)

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.

[ Parent | on HN ]

Re:Safe C++ proposal is not being continued by IshKebab on Sunday September 14, 2025 @06:25AM (#45238814)

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

[ Parent | on HN ]

Re:Safe C++ proposal is not being continued by Voultapher on Sunday September 14, 2025 @07:57AM (#45239169)

-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/...

[ Parent | on HN ]