Re: [Wireshark-dev] clang analysis
Kaul wrote: On Tue, May 4, 2010 at 10:55 PM, Stephen Fisher st...@stephen-fisher.comwrote: On Sat, May 01, 2010 at 10:57:51PM +0300, Kaul wrote: I've ran clang static analyser on SVN latest and got the following: Obviously, there's little chance I can fix all of them. I can try fix a few from the dissectors I'm familiar with, though. Oy Vey! I've just built clang from SVN and now it finds 3354 bugs. Regretfully, its report is not file based - it just shows them one after another, not sorted by file. I'm not even sure how to open a bug on so many files, and it would be quite difficult go through each file and report the bug. The report ( 6 HTMLs, uncompressed) is 1.8MB - should I perhaps zip and file a single bug? I'm almost done with the fixes to packet-ssl.c, but there are so many others... Y. I did a build using clang a while back and came to the conclusion that I would focus what appeared to be real problems (null-pointer deref, etc) as for me life was too short to try to fix all the dead code etc. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] clang analysis
On Sun, May 09, 2010 at 11:56:50PM +0300, Kaul wrote: Oy Vey! I've just built clang from SVN and now it finds 3354 bugs. Regretfully, its report is not file based - it just shows them one after another, not sorted by file. I'm not even sure how to open a bug on so many files, and it would be quite difficult go through each file and report the bug. The report ( 6 HTMLs, uncompressed) is 1.8MB - should I perhaps zip and file a single bug? I'm almost done with the fixes to packet-ssl.c, but there are so many others... Sorry, I wasn't clear on what I meant. If you could open a bug just saying that you're running clang version whatever and it found thousands of bugs, that's enough :). It's just a hint to others to run clang on their own and see what can/should be fixed. -- Steve ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] clang analysis
On Sat, May 01, 2010 at 10:57:51PM +0300, Kaul wrote: I've ran clang static analyser on SVN latest and got the following: Obviously, there's little chance I can fix all of them. I can try fix a few from the dissectors I'm familiar with, though. Every little bit of assistance helps! What OS are you running clang on? I started to compile Wireshark on MacOS 10.6 once I saw your message the other day and ran into a few problems it noticed that gcc doesn't seem to care about. The main one was what I termed backwards overflow ;). These were cases where a negative number was assigned to an unsigned 32-bit integers that makes gcc go to zero then to 2^32 and then down the right number. A hex number represents it easily in text, but the 4.2 million or so is hard to follow. Please open a bug report at https://bugs.wireshark.org with just some of the details on what you found - you don't have to list everything of course. It sounds like it would be best tackled by others using clang also I would think. Thanks! -- Steve ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] clang analysis
Hi, I've ran clang static analyser on SVN latest and got the following: Bug Summary Bug TypeQuantityDisplay? All Bugs2769 Dead store Dead assignment1692 Dead increment998 Dead initialization25 Dead nested assignment32 Logic errors Null dereference21 Use of uninitialized value1 Obviously, there's little chance I can fix all of them. I can try fix a few from the dissectors I'm familiar with, though. Some (most of the dead) might/probably are removed by current generation compiler, so aren't so important to fix, although it'd be nice to. The rest may be a bit more important to fix. Example of such bug (from packet-bgp.c, which should REALLY be refactored to functions!): 2235 ti = proto_tree_add_text(subtree2, tvb, o + i + aoff, tlen, 2236 Cluster list: %s, cluster_list_emstr-str); 15 Dereference of null pointer (cluster_list_emstr) ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
