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: Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>
Date: Thu, 17 Feb 2011 09:27:21 -0500
Guy Harris wrote:
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) {
		...
	}

And some people think

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

is a good way of coding since a typo like (NULL = a) wouldn't compile.

But (at least for me) that really is unreadable! (And finding typos like the above is, in my mind, something for the compiler to warn about.)

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.

I imagine there are going to be a LOT of "if (a)" checks in 2 million LOC. Do we really want to change them all?