Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 35975: /trunk/epan/dfilter/ /trunk/e
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.
