[Bug analyzer/106390] Support gsl::owner and/or [[gnu::owner]] attribute in -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106390 --- Comment #6 from Jonathan Wakely --- Related work: http://thradams.com/cake/ownership.html
[Bug analyzer/106390] Support gsl::owner and/or [[gnu::owner]] attribute in -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106390 --- Comment #5 from Benjamin Priour --- > I agree that this would be a problem, but instead of implying that we need > two attributes, I think this implies that we should not try to use > [[gsl::owner]] for shared ownership. If you don't try to use it for both, > the problem doesn't exist. If we discard tracking shared ownership, it indeed removes a lot of complexity, and I agree we can stick to [[gsl::owner]], and tracking moves of resources becomes much simpler. I'll go with that for now, see what tests I can do, dig a little bit.
[Bug analyzer/106390] Support gsl::owner and/or [[gnu::owner]] attribute in -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106390 --- Comment #4 from Jonathan Wakely --- I'm not sure that's worthwhile. Unique ownership is orders of magnitude more common, and lifetime is managed in smaller scopes. Tracking unique ownership within a single function is tractable, and useful. The lifetime can be analyzed for each function in isolation, without interprocedural analysis. Separate functions that correctly manage unique lifetimes compose into larger components which also correctly manage those lifetimes. Analyzing a shared lifetime pointer means also tracking reference counts, and the lifetime typically extends across functions, maybe even across shared library boundaries. Checking for correct code cannot be done for a single function in isolation. If std::shared_ptr is the main example of shared ownership, we don't need to support that in the analyzer, users should not be worrying about its correctness. But users frequently *do* write their own types that manage pointers directly with unique ownership. That's what the analyzer can help with. (In reply to Benjamin Priour from comment #3) > Let's say we only had [[gnu::owner]] for ownership, whether unique or shared. > If so, annotating [[gnu::owner]] would mean "I am becoming A (not THE) owner > of the given resource", i.e. it would always mean "shared" ownership. I agree that this would be a problem, but instead of implying that we need two attributes, I think this implies that we should not try to use [[gsl::owner]] for shared ownership. If you don't try to use it for both, the problem doesn't exist. I would caution against inventing new attributes here. The reason I suggested [[gsl::owner]] is because it is already supported by other analysers and so can be used in portable code.
[Bug analyzer/106390] Support gsl::owner and/or [[gnu::owner]] attribute in -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106390 Benjamin Priour changed: What|Removed |Added CC||vultkayn at gcc dot gnu.org --- Comment #3 from Benjamin Priour --- I think gsl::owner might be insufficient and we should rather introduce [[gnu::owner(unique)]] and [[gnu::owner(shared)]] Let's say we only had [[gnu::owner]] for ownership, whether unique or shared. If so, annotating [[gnu::owner]] would mean "I am becoming A (not THE) owner of the given resource", i.e. it would always mean "shared" ownership. Yet doing so would make the attribute only useful to check spurious deallocations of non-owned resource, as well as detect the resource has been released in the destructor, but otherwise useless to check move operations, as we cannot require a move upon acquiring a shared resource. Thus an additional attribute will be necessary anyway, either to differentiate "shared" and "unique" ownership, or to annotate a move operation. I believe [[gnu::owner(unique|shared)]] to be preferable, as we can use it to deduce a move operation, whereas a flagged move does not induce the quality of ownership.
[Bug analyzer/106390] Support gsl::owner and/or [[gnu::owner]] attribute in -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106390
--- Comment #2 from Jonathan Wakely ---
As well as checking that destructors free an "owned" member, check that move
constructors and move assignments transfer ownership correctly, i.e. leave the
previous owner empty, and for move assignment, ensure any previous value in the
LHS is freed before being replaced i.e. given class Foo with member
gsl::owner m_ptr:
Foo&
Foo::operator=(Foo& rhs)
{
m_ptr = rhs.m_ptr;
rhs.m_ptr = nullptr;
return *this;
}
flag a bug, because the previous value of m_ptr is overwritten without freeing
it.
[Bug analyzer/106390] Support gsl::owner and/or [[gnu::owner]] attribute in -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106390 --- Comment #1 from Jonathan Wakely --- For more details see https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#gslview-views
