LWN: Comments on "Smatch: pluggable static analysis for C" https://lwn.net/Articles/691882/ This is a special feed containing comments posted to the individual LWN article titled "Smatch: pluggable static analysis for C". en-us Thu, 18 Sep 2025 22:42:05 +0000 Thu, 18 Sep 2025 22:42:05 +0000 https://www.rssboard.org/rss-specification lwn@lwn.net Smatch: pluggable static analysis for C https://lwn.net/Articles/693110/ https://lwn.net/Articles/693110/ error27 <div class="FormattedComment"> I hadn't testing wine for some time.<br> <p> I have pushed an update so you don't need to do Neil's -I/usr/include/x86_64-linux-gnu/ work around that he mentions in the other comment. Also I changed it to ignore _Pragma() instead of dying. There are still one or two files that don't compile because they use the tools/winegcc/winegcc wrapper instead of regular gcc and I didn't investigate how to deal with that.<br> <p> The main thing though was that it wasn't ignoring the ok() macro and the list of no return functions was out of date. I also updated the smatch_scripts/ directory to take a -p=&lt;project&gt; argument. The thing which I haven't managed to do yet is to make the cross function db work properly.<br> <p> CHECK="~/progs/smatch/devel/smatch --file-output --full-path -p=wine" \<br> make CC="~/progs/smatch/devel/cgcc"<br> find -name \*.c.smatch -exec cat \{\} \; &gt; smatch_warns.txt<br> <p> You could pass a -j8 or whatever to the make to speed things up.<br> <p> The warnings are still pretty low quality compared to the kernel because I've massaged Smatch for the kernel's quirks. :/ The kernel has a pretty uniform style so there are some issues I never noticed until now.<br> </div> Fri, 01 Jul 2016 14:25:03 +0000 Smatch: pluggable static analysis for C https://lwn.net/Articles/693054/ https://lwn.net/Articles/693054/ neilbrown <div class="FormattedComment"> <font class="QuotedText">&gt; I was wondering if the last paragraph indicates that the author was able to use sparse on a smaller and possibly out-of-tree body of code?</font><br> <p> It certainly does. I placed the line<br> <p> smatch -I/usr/include/x86_64-linux-gnu/ $(CPPFLAGS) $&lt;<br> <p> in the appropriate place in my Makefile and it runs smatch and occasionally tells me that I assumed something might be NULL and then dereferenced that value, or that I'm calling malloc() with the wrong size.<br> <p> I didn't try generating a symbol database. It still performs a number of tests without it.<br> <p> </div> Thu, 30 Jun 2016 04:57:58 +0000 Smatch: pluggable static analysis for C https://lwn.net/Articles/693034/ https://lwn.net/Articles/693034/ moorray <div class="FormattedComment"> Smatch is a bit hard to use. I recently spent few hours trying to generate symbol database and then to test out-of-the-tree repo but failed and gave up :( I was wondering if the last paragraph indicates that the author was able to use sparse on a smaller and possibly out-of-tree body of code?<br> </div> Wed, 29 Jun 2016 18:31:58 +0000 Smatch: pluggable static analysis for C https://lwn.net/Articles/692552/ https://lwn.net/Articles/692552/ mstefani <div class="FormattedComment"> I am not sure that the "wine" project in Smatch works. I have been using the old gcc based Smatch successfully on Wine and Dan has been very kind to port some of the stuff I used over to the new Smatch. But for Wine the new Smatch suffered from two big problems:<br> - Sparse couldn't compile Wine.<br> - I'm not a compiler or even CS guy and sparse and the new Smatch were too steep for me to learn and fix.<br> <p> So I kept using the old Smatch for as long as it still run and was able to compile Wine. By that time coccinelle came along and I started using that. Coccinelle had the advantage of being useful also for my other Wine work aka massive automated code changes.<br> Though not everything can be done with coccinelle and I always planned to go back and look at Smatch. Thanks for the article.<br> <p> <p> </div> Thu, 23 Jun 2016 21:41:20 +0000