--- Comment #5 from RJVB <> ---
What can possibly wrong about the fix? If a variable shouldn't be NULL and
there are apparently reasons why it can happen outside of reasonable
precautions, NOT checking is wrong. 

And clearly this is NOT a situation where an occasional failing dynamic_cast is
something from which you cannot recover (i.e. it's a transient failure), so
there's no need to abort when it happens in code built in production mode. And
IMHO that's independent from a possible fix for *this* case of failing

I can try to add the macro to both ClangProblem and the other mentioned class
to see if that changes anything. Do I have to include anything additional or
make other changes to do this?

Anyway, I doubt a bit if that will be the ideal fix because I'm only seeing the
error messages in question sporadically. There's been only instance where this
kind of fix has been a sufficient solution (ktimetracker in KDE PIM4), but
there the dynamic_cast failed systematically. I'm currently seeing the errors
often because of KDE PIM4, but that code apparently handles the issue
elegantly, and I have failed to figure out which classes to export to make the
error go away, probably somehow related to the fact that the base class is
purely abstract.

I should verify first if we're in the same situation here, i.e. if the cast
ever succeeds. It almost certainly does, because otherwise I should caught this
crash much earlier.

FWIW, I think this doesn't have anything to do with Mac vs. Linux, but with
libc++ vs. libstdc++ .

You are receiving this mail because:
You are watching all bug changes.

Reply via email to