[llvm] [libc++abi] Handle null pointer-to-object: Issue #64593 (PR #68076)

[Iain Sandoe via llvm-commits]

iains wrote:

> I'm... not sure it's okay to change v-tables in the `std::type_info` hierarchy like this. In theory it's non-ABI and purely an internal implementation detail of the C++ runtime, but in practice there are some other subclasses out there, like in the ObjC runtime.

My, perhaps flawed, understanding is that Objective-C is supposed to inherit from the parent language and thus, absent a specification to the contrary, a bug in the exception handling here would also be a bug in the Objective-C exception handling, thus it should also import the fix)?

> I know that the bot is telling you to reformat, but that is making it a lot more difficult to review this patch; please just ignore the bot or do the reformat in a separate PR.

(agreed that the layout change obfuscates some of the change purpose - most of it is just initialising the new bool in __dynamic_cast_info).  However, if you like I can find my original patch (without the layout changes) and force-push that here?

> Let me try to understand the basic problem here. We have an exception that's dynamically a null pointer statically typed as `Base*`, and we're testing whether it's caught by `Derived*`. This should succeed only if there is a unique public `Base` subobject in `Derived`. Catching is built on top of the machinery for `dynamic_cast`, but the exception path can't be handled the same way it is for `dynamic_cast` for two reasons:
> 
> * First, the `dynamic_cast` operator on a null pointer just produces a null pointer unconditionally; it is not meaningful to ask whether the cast "succeeded".  That is not true with EH, because we have to decide whether we enter the `catch` block (or pass the EH filter).
> * Second, in `dynamic_cast` we know both types statically and could therefore evaluate the unique-public-subclass condition statically if we needed to.  This is not possible with EH because the type relationship is dynamic.
> 
> So EH needs a way to check the has-unique-public-subclass condition without looking at actual objects. Makes sense.

Right, exactly.
Two additional points:

1) there should be NFC to dynamic casts - for them, the __dynamic_cast_info object is initialised to say "we have a pointee object".  If that is untrue in some relevant way it's a different bug.

2) At the moment, I cannot see a way to fix this that does not involve changing the private implementation - and thus potentially impacting Objective-C.




https://github.com/llvm/llvm-project/pull/68076