public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug analyzer/106390] New: Support gsl::owner<T> and/or [[gnu::owner]] attribute in -fanalyzer Date: Thu, 21 Jul 2022 17:38:21 +0000 [thread overview] Message-ID: <bug-106390-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106390 Bug ID: 106390 Summary: Support gsl::owner<T> and/or [[gnu::owner]] attribute in -fanalyzer Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Blocks: 97110 Target Milestone: --- Check that "owned" resources are freed: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c31-all-resources-acquired-by-a-class-must-be-released-by-the-classs-destructor This would require the analyzer to recognize the gsl::owner alias and treat it specially. The definition of gsl::owner is simply a typedef for a raw pointer: template <class T, class = std::enable_if_t<std::is_pointer<T>::value>> using owner = T; (Reference impl at https://github.com/microsoft/GSL but I plan to add a <gsl> header to libstdc++ too, making use of GCC extensions.) The point is to permit static analysis to treat that pointer differently to a non-owning pointer (which just aliases some other object that isn't owned). If the code just uses T* it's unclear what the semantics of that member are. If it uses gsl::owner<T*> it's explicit that the class "owns" that pointer and is directly responsible for deallocating it. Pointers stored as a gsl::owner must be freed in a destructor, unless ownership has been transferred to another object via move semantics. class S { public: S(); S(S&&); ~S() { } // bug! owned resource not freed private: struct Impl; gsl::owner<Impl*> m_pimpl; }; A more general solution would be a new [[gnu::owner]] attribute that can be added to any data member to say it owns a resource. So the following would be equivalent to the example above: class S { public: S(); S(S&&); ~S() { } // bug! owned resource not freed private: struct Impl; [[gnu::owner]] Impl* m_pimpl; }; This attribute would be extensible to non-pointer types such as file descriptors and other resources where ownership is transferred by move constructors and freed by destructors etc. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97110 [Bug 97110] [meta-bug] tracker bug for supporting C++ in -fanalyzer
next reply other threads:[~2022-07-21 17:38 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-07-21 17:38 redi at gcc dot gnu.org [this message] 2022-07-21 17:43 ` [Bug analyzer/106390] " redi at gcc dot gnu.org 2022-07-21 17:46 ` redi at gcc dot gnu.org 2023-06-08 17:00 ` vultkayn at gcc dot gnu.org 2023-06-08 19:17 ` redi at gcc dot gnu.org 2023-06-08 19:44 ` vultkayn at gcc dot gnu.org 2024-03-04 15:58 ` redi at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-106390-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).