Hi, the topic is definitely relevant.   Do you allow C++ references?   Do the smart pointers incur size or speed disadvantages compared to C pointers? I.e. have you just used the type system for annotations or do you change the runtime behavior compared to classic pointers.   Do you handle multi-threading?   Do you use ownership hierarchies of objects and deduce lifetime?   Do you use call hierarchies of functions and deduce lifetime?   Can code make to pass the tests with annotations or with refactoring?     -----Ursprüngliche Nachricht----- Von:Thomas Krogh Lohse via Std-Proposals <std-proposals_at_[hidden]> Gesendet:So 01.06.2025 10:32 Betreff:[std-proposals] Memory Safety in C++ via Safe Subset and Static Analysis - Master’s Thesis Summary An:std-proposals_at_[hidden]; CC:Thomas Krogh Lohse <tlohse20_at_[hidden]>; 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] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals