On Sun, 1 Jun 2025, 09:32 Thomas Krogh Lohse via Std-Proposals, <
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]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>