None

[Mark S. Miller <mark>]

Date: Mon, 20 Nov 89 00:40:07 PST
   From: tribble (Eric Dean Tribble)

   ... This made me realize
   that my discomfort with cast was always its ability to leap from
   branch to branch in the inheritance tree.  ...
   In the back of my mind, I keep thinking that this is how the current
   cast operation works, even though it's not defined that way.  

Listen to the back of your mind Luke.  The CAST macro works this way
for a simple reason.  Let's say we have the following hierarchy:

CLASS(T,Heaper) ...
 CLASS(T1,T)
  CLASS(T11,T1)
 CLASS(T2,T)

T1 * p;

Let's examine the following expressions:

a) CAST(T11,p)	// sensible expression, and works if p actually points
at a kind of T11.

b) CAST(T,p)  // always works, but should always be unnescesary since
a T1* should be useable anywhere a T* is.  This could be checked for
by XLint, but seems unneeded.

c) CAST(T1,p) // always works, but is even sillier that #b.

d) CAST(T2,p) // can never work unless there has already occurred a
**SERIOUS** uncaught runtime error in the program.  This is because
the compile-time-type of p is already T1*, so it would be highly
exceedingly awfully dangerously strange for it to point at something
that isn't a kind of T1.  Given single inheritance, anything that
is a kind of T1 cannot be a kind of T2.

Granted it isn't a compile time check, but it is a runtime check that
is always guaranteed to fail.  Therefore, a coverage check *must*
catch it.

Unless p == NULL when we do the coverage check.  

I do think it's possible to figure out an expansion of the CAST macro
such that only #a and #c compile, but I'm not inclined to try unless
someone asks me to.