Date: Tue, 22 Jul 2025 22:03:30 -0400
FYI I just updated C++ Superset to version 2.0.0. It's not perfect but
it can handle very complex templates as you can see in
devel/memoryleak11.cpp:
https://static.fornux.com/c-superset/
It's also dual license and free for open source usages.
Enjoy!
On 6/1/25 04:32, Thomas Krogh Lohse via Std-Proposals 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
>
it can handle very complex templates as you can see in
devel/memoryleak11.cpp:
https://static.fornux.com/c-superset/
It's also dual license and free for open source usages.
Enjoy!
On 6/1/25 04:32, Thomas Krogh Lohse via Std-Proposals 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
>
-- Email Signature Fornux Logo <https://www.fornux.com/> *Phil Bouchard* LinkedIn Icon <https://www.linkedin.com/in/phil-bouchard-5723a910/> Founder & CEO T: (819) 328-4743 E: phil_at_[hidden]| www.fornux.com <http://www.fornux.com> 720 Oliver Ave, San Diego, CA, 92109 The Best Predictable C++ Memory Manager <https://static.fornux.com/c-superset/> Le message ci-dessus, ainsi que les documents l'accompagnant, sont destinés uniquement aux personnes identifiées et peuvent contenir des informations privilégiées, confidentielles ou ne pouvant être divulguées. Si vous avez reçu ce message par erreur, veuillez le détruire. This communication (and/or the attachments) is intended for named recipients only and may contain privileged or confidential information which is not to be disclosed. If you received this communication by mistake please destroy all copies.
Received on 2025-07-23 02:03:34