[cfe-dev] Clang Static Analyzer Round Table

[Deep Majumder via cfe-dev]

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/c3428ad6/attachment.html>