C++ PATCH: throw (T *)NULL and dynamic_cast

[Nathan Sidwell]

Jason Merrill wrote:
> Returning (void*)1 from __throw_type_match_rtti doesn't work, as there may
> be old code that calls __throw_type_match_rtti and does not know to adjust
> back.  We should indicate success or failure separately from the return
> value, as in my patch.
Okay, I took the line that old binaries which throw NULL would behave brokenly
anyway. Changing their brokenness wouldn't matter. (As I said towards the end
of http://egcs.cygnus.com/ml/gcc-patches/1999-06/msg00226.html ) Thus avoiding
two versions of throw_type_match_rtti.

> As I read the standard, if downcasting from sub to target is ambiguous, the
> cast can still succeed if there is only one public base of type target, as
> illustrated in the testcase below, which is not fixed by your patch.
I disagree. I presume you're talking about 5.2.7/8 2nd option. This uses the
unfortunate phrase 'unambiguous public base'. does this mean an unambiguous
base which happens to be public or a public base which happens to be
unambiguous. I.e. which do we do first? Martin and I decided that this must
mean an unambiguous base which happens to be public, becase clause 11 says that
accessibility is applied after visibility. Elsewhere the standard uses a number
of different phrases which all (seem to) indicate unambiguous (across all) and
public. _But_ I now notice that 5.2.7/8 says `unambiguous <tt>public</tt> base'
does this font difference impart a different meaning? Whichever way one
interprets 5.2.7/8 one can construct program's who's behaviour changes when the
access is changed -- the question is which did the committee intend?

> think the problem is that the way the code is currently divided doesn't
> match the two-stage process described in the standard -- namely, try to
> find a downcast, then if that fails, try to find a cross-cast.
One of the problems in searching the class inheritance tree I found was that
it's the wrong way up. Namely you start at the most derived object and have to
look upwards to its base classes to find the type originally supplied. Hence
you can end up locating the cross cast in looking for the downcast. The code
caches this information, but currently loses that cache, should the cross cast
be ambiguous.

An additional complication with this code is that it is used in two situations
1) in dynamic_cast where we will be down casting or cross casting
2) in catch where we will be up casting

Maybe treating these with different functions will make the whole thing
simpler, and allow dynamic_cast in one pass through the heirarchy. Does that
sound a better plan?

> I think we can do everything in one pass, though; we would just record our
> current status for both stages at once, remembering whether we've seen a
> downcast, a public T, and a public route to v, or ambiguous versions of the
> same.
Yes this is what my patch attempts to do (using the above interpretation of the
standard).

If we are cleaning up this bit of runtime, what about the comments I said at 
http://egcs.cygnus.com/ml/gcc-patches/1999-06/msg00363.html , namely
1) The NEED_PUBLIC parameter to dcast is always non-zero. Perhaps it could be
removed.

Now, before I go off and bash at this, we need to determine what the correct
interpretation of 5.2.7/8 is.

nathan

-- 
Dr Nathan Sidwell :: Computer Science Department :: Bristol University
        I have seen the death of PhotoShop -- it is called GIMP
nathan@acm.org  http://www.cs.bris.ac.uk/~nathan/  nathan@cs.bris.ac.uk