5

No doubt there are other, perhaps better ways to do this, but I'm trying to understand what is going on here.

In the below example, coverity is reporting a FORWARD_NULL defect on the fourth line.

double? foo = null;
double bar = 1.23;
foo += bar;
System.Windows.Point point = new System.Windows.Point(foo,bar);  

it reports:

assign_zero: Assigning: foo = null.

on the foo += bar line.

in += Operator (C# Reference), I see that x += y is equivalent to x = x + y, and in Using nullable types (C+ Programming Guide), I see that

These operators [the binary operator] produce a null value if one or both operands are null

so is that what is going on? foo += bar becomes foo = foo + bar and since foo is null, foo + bar is null?

Michael J.
  • 349
  • 1
  • 10
  • Yeah, foo remains as null – Richard Boyce Mar 08 '19 at 15:13
  • 3
    Is the *defect* being reported on line three, or is line three *evidence* for a defect that comes later? Normally the forward null defect is reported at the location where a null dereference can throw, but there's no such dereference here. – Eric Lippert Mar 08 '19 at 16:34
  • @Eric Lippert you are correct. The defect is reported a few lines later where foo is being dereferenced. I'll update the question – Michael J. Mar 08 '19 at 20:02
  • OK good, but the program fragment you gave shouldn't even *compile*. `Point` takes a double, not a nullable double. There's no reason to run code through Coverity if it doesn't even compile! – Eric Lippert Mar 08 '19 at 22:54

1 Answers1

5

so is that what is going on? foo += bar becomes foo = foo + bar and since foo is null, foo + bar is null?

Yes.

spodger
  • 1,668
  • 1
  • 12
  • 16