[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [csmith-dev] Fwd: Csmith TODO list



On Mon, Nov 21, 2011 at 11:52 PM, John Regehr <regehr@cs.utah.edu> wrote:
Pascal I don't understand what you mean "too runtimy".  It's a purely runtime property -- you can't be too runtimy to check it.  If we had the stupidest possible compiler (no register allocation, etc.), Valgrind would succeed perfectly, unless it has bugs, because every variable would reside in memory and would be shadowed.

I probably picked the wrong non-word here,but I meant the same thing as you: the compiler would have to be stupider than usual not to erase at least some of the uninitialized accesses from the program so that they are invisible at execution.

Compiler people can be unfathomable. I'm not surprised that one of them told you they would like the property being discussed to hold. On the other hand, false positives in Clang should be reported:

"Please help us in this endeavor by reporting false positives" (http://clang-analyzer.llvm.org/ )

Furthermore, to me, the idea of the surrounding paragraph is that while the developers acknowledge the compromises inherent to static analysis, they aim a low rate of false positive for ordinary, human-written programs. Random programs, even reduced enough to be understandable, are still not representative. In the worst case, the developers may mistake the map for the territory and adjust Clang's delicate trade-off in reaction to your reports, making the compiler a worse assistant for writing programs by hand.

And I don't think they would consider compiling the program below to take O(n) stack either,

{ int t[2];
..
}
{ int t[2];
 ..
}
...

Pascal