> At the end of the conditional, all the compiler can determine is that> pstr *might* point to stack-allocated memory. Even more difficult:> pstr = foo(&stack_array[0]);> To detect the *potential* error, a compiler has to be able to solve> the interprocederal points-to problem, which is highly nontrivial.

My solution to this problem is simply to program in a language where
such gaffes are forbidden; Java, Modula-3, Scheme, and ML are all fine
choices. For some reason, most other people don't see the obvious
superiority of these solutions, and they program in other languages
like C and C++. I quit worrying about trying to educate people out of
shooting themselves in the foot, and have spent the last few years
either increasing performance of the firearms ("now with faster
bullets"), or building better diagnostic equipment ("that there is a
hole in your foot").

> In general, the kind of defect detection you're interested in is very> difficult to do at compile time. You're much better off using a C> interpreter like Saber C (are they still around?). The interpreter> can much more easily check such conditions at run time.

> [It's certainly useful to warn about returning a direct reference to an auto> variable, which is an error 99+% of the time. Saber C is indeed still around,> now it's called Code Center and the vendor is called Centerline. -John]

Code Center is probably still available, but they sell a newer product
called "C++ Expert", which also handles C just fine. I ran your
trickier example through the demo server that CenterLine has on the
web (http://lumiere.centerline.com:9000, when the machine isn't
crashed), and it did a pretty good job of complaining about it and
pointing out the offending line (this is running in batch mode, of
course).