[cfe-dev] Clang Static Analyzer Round Table

[Artem Dergachev via cfe-dev]

It's 9:30 - 10:30 Wednesday (PST / UTC-8), already up on 
https://llvm.swoogo.com/2021devmtg/agenda

On 11/15/21 3:40 AM, Deep Majumder wrote:
> Are we having this? If so, when?
>
> On Thu, Oct 28, 2021 at 9:24 PM Gábor Márton <martongabesz at gmail.com> 
> wrote:
>
>     + Randell
>
>     Hi Randell,
>
>     Thank you for your email, I am forwarding it to the list.
>
>     >  Is the list set up to block new subscribers from posting until
>     moderators review?
>     I really don't know, maybe someone in the list will know.
>
>
>     On Thu, Oct 28, 2021 at 3:41 PM Randell Jesup <rjesup at mozilla.com>
>     wrote:
>
>         On 10/26/2021 4:09 AM, Gábor Márton via cfe-dev wrote:
>>         Hi CSA developers,
>>
>>         I've submitted a round table request for the upcoming Dev
>>         Meeting (Nov 17-19). Would be great to have a discussion.
>>         Please also invite colleagues who you think might be interested.
>
>
>         Hi Gabor.  I recently joined the cfe-dev mailing list, but
>         have been unable to post to it.  Is the list set up to block
>         new subscribers from posting until moderators review?   Thanks
>
>
>         This is what I was trying to send:
>
>         Subject: Thread-safety analysis rough edges
>
>         I've been working with -Wthread-safety, and have run into a
>         few rough edges.
>
>         One is RAII unlockers.   As stated in the known limitations,
>         it doesn't handle an RAII unlocker and gets very confused,
>         leading to follow-on false positives.   Is the only reasonable
>         solution to simply not annotating the RAII unlocker class, and
>         live with the analysis being wrong during the unlocked section?
>
>         Is there any ongoing work to resolve this issue?
>
>         I notice the work done by WebKit to use this functionality to
>         do static thread assertions
>         (https://webkit-search.igalia.com/webkit/source/Source/WTF/wtf/ThreadAssertions.h).
>         There seems to be some value here (witness the shift from
>         lock-centric names), but examples on how to use it would be
>         good, similar to the mutex.h in the docs.
>
>         Related: There are a number of usage patterns for Mutexes that
>         don't lend themselves easily to thread-safety annotations.  An
>         example would be a item written to from only a single thread,
>         but read from other threads.   The lock must be held to write
>         it, and all off-writer-thread accesses must lock to access
>         it.  However, on-writer-thread accesses *don't* need to lock,
>         and will generate false positives.  (There are other Mutex
>         patterns, like free access until the item is made available to
>         other threads, or after all other threads are known to have
>         exited, and more, which aren't easily covered.)
>
>         What's the best way to handle this, other than not adding
>         GUARDED_BY() or using NO_THREAD_SAFETY_ANALYSIS?  Could we
>         mark an item as requiring one of a set of capabilities?  (i.e.
>         on the correct thread OR holds the mutex?)
>
>         Thanks,
>
>         Randell Jesup, Mozilla
>
>
>     On Thu, Oct 28, 2021 at 12:23 AM Artem Dergachev
>     <noqnoqneo at gmail.com> wrote:
>
>         +Andrew and Bruno who attended our tiny cozy static analyzer
>         round table
>         at the bay area meetup!
>
>         Andrew, you have some notes from that round table, do you
>         think it makes
>         sense to share them in this mailing list thread?
>
>         On 10/26/21 12:26 PM, Artem Dergachev wrote:
>         > +Deep because he expressed interest.
>         >
>         > Yay! Yes, absolutely, let's have that.
>         >
>         > On 10/26/21 1:09 AM, Gábor Márton wrote:
>         >> Hi CSA developers,
>         >>
>         >> I've submitted a round table request for the upcoming Dev
>         Meeting
>         >> (Nov 17-19). Would be great to have a discussion.
>         >> Please also invite colleagues who you think might be
>         interested.
>         >>
>         >> Thanks,
>         >> Gabor
>         >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20211115/9155be35/attachment.html>