[Mono-bugs] [Bug 79486][Wis] Changed - gendarme NullDerefRule shows error when code is ok

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by atomb at soe.ucsc.edu.

http://bugzilla.ximian.com/show_bug.cgi?id=79486

--- shadow/79486	2006-09-25 08:09:38.000000000 -0400
+++ shadow/79486.tmp.14624	2006-09-29 15:41:11.000000000 -0400
@@ -40,6 +40,37 @@
 test case
 
 
 ------- Additional Comments From marek.sieradzki at gmail.com  2006-09-25 08:09 -------
 It fails when code referencing something that maybe null is avoided by
 exception and when it's avoided by if. 
+
+------- Additional Comments From atomb at soe.ucsc.edu  2006-09-29 15:41 -------
+It turns out that this problem is more subtle than it seems at first.
+It arises from the differences in semantics between the C# source
+language and the .NET bytecode. In the source language, it seems
+trivial to see that the example posted with the bug report has no
+errors. However, if you consider how the code is compiled, it's not so
+obvious. Here's part of the output of monodis:
+
+        IL_0000:  call string class Test::Something()
+        IL_0005:  stloc.0
+        IL_0006:  ldloc.0
+        IL_0007:  brfalse IL_0017
+
+        IL_000c:  ldloc.0
+        IL_000d:  callvirt instance string string::ToLower()
+        IL_0012:  call void class
+[mscorlib]System.Console::WriteLine(string)
+        IL_0017:  ret
+
+It's entirely possible that a (very strange) compiler could insert
+code in between IL_0006 and IL_0007 that changes the value of local 0.
+Then, when the branch occurs, we do indeed know whether or not the top
+of the stack is null or not, but that value is discarded. We know
+nothing about whether or not local 0 is null or not. Of course, no
+sane compiler (for C#) would be likely to do this, and it is possible
+to get around the problem (as FindBugs does). However, it would
+require some non-trivial changes to the architecture of the analysis,
+because it goes beyond the basic framework of dataflow analysis, and
+I'm not sure when I'll have the time to make them.
+