easy to miss bug (even in structured debug)

[Eric Dean Tribble <tribble>]

How would the code-checker handle this?

	   T * p;

	   p = someT1P;
	   ...
	   if (VERY screwy expression that happens always to be true) {
		   p = someT2P;
	   }
	   ...
*	   subTakingOnlyT2(p);

   Remember, this is a major oversimplification of what it would see.

Think of T2 as a subclass of T1.  Your program has a type violation on
*'d line.  Consider that any T2 is a subType of void (T1).
Type-checking protects us from errors arising from spurious,
uncontrolled polymorphism.  I consider NULL vs. T* to be pointer
polymorphism, and I want it explicitly controlled with the same
mechanisms that we use for controlling other polymorphism.

   The point I'm trying to make is that, in the general case, determining
   what a pointer may contain by reading the code is NOT simple.  You must
   instead restrict the input code so the test can be made.

I am talking about a structured restriction on the input code.  It
would be upward compatible from our current code, so we wouldn't have
to rewrite anything.

   Would the point have been made more clearly if the last statement had been:

	   if (IS_KIND_OF(T1,p)) { halt(); }

This exemplifies the possible abuses of polymorphism.  It's just a bad
program design.  MarkM's DISPATCH macro elegantly avoids this by
converting run-time types to compile-time types, and then using
overloading.  The halting behavior can then be statically associated
with type information.

This should probably continue in person.  Thanks,
dean