> On Aug 21, 2023, at 4:25 PM, Ryosuke Niwa via webkit-dev > <webkit-dev@lists.webkit.org> wrote: > > Hi all, > > It has been a while since I last announced the plan to adopt smart pointers > using clang static analyzer: > https://lists.webkit.org/pipermail/webkit-dev/2020-September/031386.html > > Here are some updates. > > > 1. We’ve made a progress in implementing all the rules including rules for > local variables in clang static analyzer: > https://github.com/WebKit/WebKit/wiki/Smart-Pointer-Usage-Guidelines#rules-for-using-ref-counted-objects > > > 2. We also have a new kind of smart pointers: CheckedRef > <https://github.com/WebKit/WebKit/blob/main/Source/WTF/wtf/CheckedRef.h> / > CheckedPtr > <https://github.com/WebKit/WebKit/blob/main/Source/WTF/wtf/CheckedPtr.h>. > These behave like Ref and RefPtr in that they increment & decrement a counter > in an object but unlike them don’t extend the lifetime of the object. > Instead, the destructor of the base object release asserts that there are no > live CheckedRef / CheckedPtr left. > > I added a new section in the guide describing when to use each smart pointer > type: > https://github.com/WebKit/WebKit/wiki/Smart-Pointer-Usage-Guidelines#when-to-use-which-smart-pointer > > > 3. I wanted to describe what applying these smart pointer rules mean. A lot > of code changes needed for this work involves creating Ref / RefPtr / > CheckedRef / CheckedPtr in stack: > https://commits.webkit.org/267082@main > > One subtle thing is that even when a member variable is already Ref / RefPtr > / CheckedRef / CheckedPtr, we must create another one in stack as seen here: > https://commits.webkit.org/267108@main
(I asked rniwa to send this mail because this patch surprised me, so I hope now we can chat about it). The scope of this rule, and the … lack of elegance … at so many callsites worries me a bit. If it’s possible to automate enforcement, that might help with part of the problem, but it’s also just really not very pretty, and I wonder if someone can come up with some clever alternative solution before we go too far down this path (not me!). Alternatively, it’s possible other people OK with this syntax/requirement and I should just get over it. What do you all think? > This is because these member variables can be cleared during the course of > invoking a non-trivial function; or put it another way, it’s not immediately > obvious from the code inspection that the object pointed to stays alive over > the course of a non-trivial function call. > > - R. Niwa > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
