Date: Mon, 2 Jun 2025 15:12:41 +0000
> It is certainly promising and worthwhile. Good to see people are working on this important subject.
I agree, especially given the U.S. governments statements last year.
> The ability to enable/disable the feature in parts of the program.
Currently, I've added an attribute that allows developers to opt-out of the check, along with specifying functions and namespaces to omit through the commandline. Is there some better way to do this?
> The ability to include/exclude certain checks for a given run of the analyzer.
What do you mean exactly by that? Like, exclude use-after-move, but have the others? Or more broad, exclude the borrow checker, but have the lifetime?
> Good to have: It would be useful to be able to restrict the subset even more than the default “safe subset” by enabling specific criteria. For example, a feature, e.g., goto, could be controversial and not be excluded from the “safe subset,” but a user could exclude it in their own sub-"safe subset”. Or, it could be versioned, or, modularized.
I think this is a very nice and neat idea, though I have no idea how to (realistically) do this.
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Maryam via Std-Proposals <std-proposals_at_[hidden]>
Sent: Monday, June 2, 2025 5:27 AM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Maryam <maryam_at_[hidden]>
Subject: Re: [std-proposals] Memory Safety in C++ via Safe Subset and Static Analysis - Master’s Thesis Summary
It is certainly promising and worthwhile. Good to see people are working on this important subject.
Having said that, users would want control, so a couple of must-have features would be:
1. The ability to enable/disable the feature in parts of the program.
2. The ability to include/exclude certain checks for a given run of the analyzer.
Without knowing how this actually works, it is hard to tell if this makes sense or is doable:
Good to have: It would be useful to be able to restrict the subset even more than the default “safe subset” by enabling specific criteria. For example, a feature, e.g., goto, could be controversial and not be excluded from the “safe subset,” but a user could exclude it in their own sub-"safe subset”. Or, it could be versioned, or, modularized.
On Jun 1, 2025, at 04: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.
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
I agree, especially given the U.S. governments statements last year.
> The ability to enable/disable the feature in parts of the program.
Currently, I've added an attribute that allows developers to opt-out of the check, along with specifying functions and namespaces to omit through the commandline. Is there some better way to do this?
> The ability to include/exclude certain checks for a given run of the analyzer.
What do you mean exactly by that? Like, exclude use-after-move, but have the others? Or more broad, exclude the borrow checker, but have the lifetime?
> Good to have: It would be useful to be able to restrict the subset even more than the default “safe subset” by enabling specific criteria. For example, a feature, e.g., goto, could be controversial and not be excluded from the “safe subset,” but a user could exclude it in their own sub-"safe subset”. Or, it could be versioned, or, modularized.
I think this is a very nice and neat idea, though I have no idea how to (realistically) do this.
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Maryam via Std-Proposals <std-proposals_at_[hidden]>
Sent: Monday, June 2, 2025 5:27 AM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Maryam <maryam_at_[hidden]>
Subject: Re: [std-proposals] Memory Safety in C++ via Safe Subset and Static Analysis - Master’s Thesis Summary
It is certainly promising and worthwhile. Good to see people are working on this important subject.
Having said that, users would want control, so a couple of must-have features would be:
1. The ability to enable/disable the feature in parts of the program.
2. The ability to include/exclude certain checks for a given run of the analyzer.
Without knowing how this actually works, it is hard to tell if this makes sense or is doable:
Good to have: It would be useful to be able to restrict the subset even more than the default “safe subset” by enabling specific criteria. For example, a feature, e.g., goto, could be controversial and not be excluded from the “safe subset,” but a user could exclude it in their own sub-"safe subset”. Or, it could be versioned, or, modularized.
On Jun 1, 2025, at 04: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.
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-02 15:12:49