ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 35975: /trunk/epan/dfilter/ /trunk/e

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Thu, 17 Feb 2011 00:58:32 -0800
On Feb 17, 2011, at 12:25 AM, Stig Bjørlykke wrote:

> On Thu, Feb 17, 2011 at 9:15 AM,  <guy@xxxxxxxxxxxxx> wrote:
>>  OK, let's try a couple more explicit checks against NULL, to see whether
>>  that de-confuses Microsoft's code analyzer.
> 
> Do we really want such changes?
> Personally I think it makes the code harder to read.

Some think

	if (a) {
		...
	}

is easier to read, others think

	if (a != NULL) {
		...
	}

is easier to read, while some think

	if (!a) {
		...
	}

is easier to read, and some think

	if (a == NULL) {
		...
	}

is easier to read.  Unfortunately, Microsoft's static analyzer, which *does* appear to be finding some real bugs, thinks

	if (a != NULL) {
		...
	}

and

	if (a == NULL) {
		...
	}

are easier to correctly analyze in some if not all cases, as in "it can't analyze the other variants correctly"; until the static analyzer is fixed, it's a tradeoff between the changes

	1) making the code harder to read for some and easier to read for others

and

	2) eliminating a bunch of chaff that doesn't have to be filtered out of the output of the static analyzer to find the wheat.

It would be nice if the code analyzer bug in question didn't exist, but the output of the code analyzer looks useful enough that I'd prefer not to have to remember which "dereferecing a null pointer" complaints are bogus every time I look at the code analyzer output.