From: Peter Senna Tschudin <peter.senna@gmail.com>
To: Wolfram Sang <wsa@the-dreams.de>
Cc: ksummit-discuss@lists.linuxfoundation.org,
Julia Lawall <Julia.Lawall@lip6.fr>
Subject: Re: [Ksummit-discuss] coverity, static checking etc.
Date: Mon, 12 May 2014 10:58:42 +0200 [thread overview]
Message-ID: <CA+MoWDpbRGn4sL2K29EHvbasu7BfS-OXM9oLRqJgjpj-bD_RHg@mail.gmail.com> (raw)
In-Reply-To: <20140511111034.GA6400@katana>
I think that Julia Lawall would be interested in this topic. I've
added her in CC.
On Sun, May 11, 2014 at 1:10 PM, Wolfram Sang <wsa@the-dreams.de> wrote:
>
>> Last year I had been doing the coverity scans on an almost daily basis
>> for 2-3 months. Now that we're a year in, I'd like to share some
>> results, and show some of the more common trends and bug patterns that
>> seem to pop up.
>>
>> [ spoiler: For the most part, it's all pretty positive, but we still suck ]
>>
>> It would also be good to have some more discussion about other tools
>> we could be making more use of. (Nomination: Dan Carpenter for smatch).
>
> I'm definately interested.
>
> In my workflow, I use sparse/smatch/coccicheck/cppcheck before applying
> my own work, or patches to the i2c branches. (Oh, and rats and flawfinder,
> too, but so far, they didn't point to something worthwhile.)
>
> I am interested in workflows and experiences from other people, how
> usage of static analyzers could be spread (gcc inclusion sounds great),
> how to make them more robust, etc... And by doing that, get a better
> feeling when an issue left the scope of static code checking and needs
> some proper handling.
>
> Thanks,
>
> Wolfram
>
>
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>
--
Peter
prev parent reply other threads:[~2014-05-12 8:58 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-09 17:07 Dave Jones
2014-05-09 17:19 ` josh
2014-05-09 17:31 ` Johannes Berg
2014-05-09 17:54 ` Guenter Roeck
2014-05-09 18:04 ` Mark Brown
2014-05-09 19:08 ` Jiri Kosina
2014-05-09 19:41 ` Dmitry Torokhov
2014-05-09 19:29 ` Josh Triplett
2014-05-09 17:37 ` Bjorn Helgaas
2014-05-09 20:18 ` Arnd Bergmann
2014-05-09 20:33 ` Dave Jones
2014-05-09 21:39 ` Arnd Bergmann
2014-05-09 20:33 ` Roland Dreier
2014-05-09 20:52 ` Dave Jones
2014-05-09 20:57 ` tytso
2014-05-14 11:06 ` Dan Carpenter
2014-05-11 11:10 ` Wolfram Sang
2014-05-12 6:48 ` Michal Simek
2014-05-12 9:32 ` Wolfram Sang
2014-05-14 11:09 ` Dan Carpenter
2014-05-14 13:32 ` Johannes Berg
2014-05-14 13:51 ` Guenter Roeck
2014-05-14 15:22 ` Wolfram Sang
2014-05-14 15:44 ` Peter Huewe
2014-05-14 16:36 ` Wolfram Sang
2014-05-18 16:38 ` Mauro Carvalho Chehab
2014-05-19 10:13 ` Michal Simek
2014-05-12 8:58 ` Peter Senna Tschudin [this message]
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=CA+MoWDpbRGn4sL2K29EHvbasu7BfS-OXM9oLRqJgjpj-bD_RHg@mail.gmail.com \
--to=peter.senna@gmail.com \
--cc=Julia.Lawall@lip6.fr \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=wsa@the-dreams.de \
/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: link
Be 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