Date: Sun, 1 Jun 2025 09:33:56 +0000
> Are the scalability limitations insurmountable? Or could the implementation be improved to improve scalability?
>
> How does your approach compose? Can you use it for part of a program, e.g. within a single shared library, and still link to existing code that doesn't use your solutions?
The implementation could without doubt be improved. There's research showing benefits of embedding the pointer analysis in BDDs (something I haven't done), and the analysis could easily also be optimized, both runtime- and memory-wise.
In my implementation, it's possible to add namespaces and functions (through plugin arguments) to omit, allowing exclusion of external libraries. If this approach (subset + analyses) were to be a language feature, I'm not sure what the best approach is.
________________________________
From: Jonathan Wakely <cxx_at_[hidden]>
Sent: Sunday, June 1, 2025 11:14 AM
To: C++ Proposals <std-proposals_at_[hidden]>
Cc: Thomas Krogh Lohse <tlohse20_at_[hidden]>
Subject: Re: [std-proposals] Memory Safety in C++ via Safe Subset and Static Analysis - Master’s Thesis Summary
On Sun, 1 Jun 2025, 09:32 Thomas Krogh Lohse via Std-Proposals, <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
Dear all,
I’ve just submitted my master’s thesis in Software Engineering from Aalborg University (defending it on June 6), which focuses on memory safety in C++, and I’d like to briefly share the core idea of my project.
The project defines a conservative safe subset of C++, and applies two static dataflow analyses:
* A lifetime analysis to detect use-after-free, use-after-move, and similar issues.
* A borrow checker-style analysis to ensure mutually exclusive access to resources.
The safe subset is inspired by Rust and restricts some inherently unsafe constructs:
* Pointer dereferencing
* `new` / `delete`
* `reinterpret_cast`, `const_cast`, and C-style casts
* Union field access
* Labels and `goto`
Instead, developers are encouraged (by the language) to use smart pointers for ownership and lvalue-references for borrowing, promoting RAII by default.
The analyses are implemented in a proof-of-concept Clang plugin. Users can annotate types and functions with attributes (e.g., to define smart pointer behavior or skip analysis — similar to Rust's unsafe). It’s still a prototype and has some scalability and precision limitations, but it successfully enforces the subset and detects key violations. The implementation uses Andersen’s pointer analysis.
Are the scalability limitations insurmountable? Or could the implementation be improved to improve scalability?
How does your approach compose? Can you use it for part of a program, e.g. within a single shared library, and still link to existing code that doesn't use your solutions?
I think both those questions are key to being able to deploy something like this in real world use cases. Solving memory safety problems for small, simple programs is not very interesting, those programs can be exhaustively tested and analyzed already. The real value is in solving these problems for large, complex systems.
Currently, the analysis does not handle polymorphism, exceptions, or lambdas, though I outline ideas for addressing these in future work.
If refined with a more precise pointer analysis, some over-approximation fixes, and extended support for more of C++, I believe this approach could provide safety guarantees similar to Rust — but within standard, modern C++, without requiring a new frontend or language changes.
I’d love to hear your thoughts:
* Do you see value in defining a "safe-by-default" C++ subset with opt-in unsafe features?
* Could something like this analysis model help enforce safety in future directions for the language?
I’ve tried to keep this short, but I’d be happy to elaborate on any part of the project if there's interest.
Best regards,
Thomas Lohse
>
> How does your approach compose? Can you use it for part of a program, e.g. within a single shared library, and still link to existing code that doesn't use your solutions?
The implementation could without doubt be improved. There's research showing benefits of embedding the pointer analysis in BDDs (something I haven't done), and the analysis could easily also be optimized, both runtime- and memory-wise.
In my implementation, it's possible to add namespaces and functions (through plugin arguments) to omit, allowing exclusion of external libraries. If this approach (subset + analyses) were to be a language feature, I'm not sure what the best approach is.
________________________________
From: Jonathan Wakely <cxx_at_[hidden]>
Sent: Sunday, June 1, 2025 11:14 AM
To: C++ Proposals <std-proposals_at_[hidden]>
Cc: Thomas Krogh Lohse <tlohse20_at_[hidden]>
Subject: Re: [std-proposals] Memory Safety in C++ via Safe Subset and Static Analysis - Master’s Thesis Summary
On Sun, 1 Jun 2025, 09:32 Thomas Krogh Lohse via Std-Proposals, <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
Dear all,
I’ve just submitted my master’s thesis in Software Engineering from Aalborg University (defending it on June 6), which focuses on memory safety in C++, and I’d like to briefly share the core idea of my project.
The project defines a conservative safe subset of C++, and applies two static dataflow analyses:
* A lifetime analysis to detect use-after-free, use-after-move, and similar issues.
* A borrow checker-style analysis to ensure mutually exclusive access to resources.
The safe subset is inspired by Rust and restricts some inherently unsafe constructs:
* Pointer dereferencing
* `new` / `delete`
* `reinterpret_cast`, `const_cast`, and C-style casts
* Union field access
* Labels and `goto`
Instead, developers are encouraged (by the language) to use smart pointers for ownership and lvalue-references for borrowing, promoting RAII by default.
The analyses are implemented in a proof-of-concept Clang plugin. Users can annotate types and functions with attributes (e.g., to define smart pointer behavior or skip analysis — similar to Rust's unsafe). It’s still a prototype and has some scalability and precision limitations, but it successfully enforces the subset and detects key violations. The implementation uses Andersen’s pointer analysis.
Are the scalability limitations insurmountable? Or could the implementation be improved to improve scalability?
How does your approach compose? Can you use it for part of a program, e.g. within a single shared library, and still link to existing code that doesn't use your solutions?
I think both those questions are key to being able to deploy something like this in real world use cases. Solving memory safety problems for small, simple programs is not very interesting, those programs can be exhaustively tested and analyzed already. The real value is in solving these problems for large, complex systems.
Currently, the analysis does not handle polymorphism, exceptions, or lambdas, though I outline ideas for addressing these in future work.
If refined with a more precise pointer analysis, some over-approximation fixes, and extended support for more of C++, I believe this approach could provide safety guarantees similar to Rust — but within standard, modern C++, without requiring a new frontend or language changes.
I’d love to hear your thoughts:
* Do you see value in defining a "safe-by-default" C++ subset with opt-in unsafe features?
* Could something like this analysis model help enforce safety in future directions for the language?
I’ve tried to keep this short, but I’d be happy to elaborate on any part of the project if there's interest.
Best regards,
Thomas Lohse
-- Std-Proposals mailing list Std-Proposals_at_[hidden]<mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2025-06-01 09:34:01