https://bugs.kde.org/show_bug.cgi?id=370641
--- Comment #5 from RJVB <rjvber...@gmail.com> --- 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 dynamic_cast. 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.
