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

[Jason Merrill <jason at cygnus dot com>]

>>>>> Nathan Sidwell <nathan@acm.org> writes:

 > 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.

Fair enough.  Go ahead and change it.

 >> 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.

Good point; let go with that interpretation for now.  I've asked the
committee reflector for a ruling.

That simplifies things, as an ambiguous downcast precludes a successful
cross-cast.

 > 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 so.  It would mean that the dynamic_cast code wouldn't have to
worry about null pointers, and EH wouldn't pay the price for all the
dynamic_cast complexity.

 >> 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).

Not exactly; in a cross cast, your dcast calls find_base to do another
scan of the hierarchy after we've already done one in do_dcast.  I think
this can still be done with one recursive function.

 > 1) The NEED_PUBLIC parameter to dcast is always non-zero. Perhaps it
 > could be removed.

OK.

Jason