Re: dynamic_cast problem

[Earl Purple]

Ulrich Eckhardt wrote:
> Earl Purple wrote:
> > I have a model whereby I dynamically load libraries with dlopen then
> > verify that they are the correct types with dynamic_cast.
>
> You can't do that. dlsym() returns a void pointer and that is not something
> you can safely use dynamic_cast on. If it works, it works because the
> types are right, if they aren't it might as well crash. The right cast is
> a simple static_cast.

No, I first reinterpret_cast (which is the correct one) to DLObject *
which is a base class that any dynamically loaded symbol should be an
instance of (i.e. any object that one exports in this way should be a
class instance (not a function) derived from DLObject.

I then further dynamic_cast it to the factory type and that actually
works fine. I then get that factory to produce its object and then try
another dynamic_cast on that to see if it is of a type I want. These
are all done through libraries so the regular business code does not
need to do any casting at all.

It's this last cast that failed although it has also succeeded on 2
occasions so I am guessing it is something else that is amiss. The
object did manage to identify itself (via a virtual function call) that
it was of the type I was trying to cast to.

> Other than that, there is a known bug that dynamic_cast with objects from
> shared libraries doesn't work because it compares the type information
> addresses(!) and those are different because both the main program and the
> library has a copy of it, but I can't tell you exactly which versions of
> GCC are affected nor if it really is a GCC error and not a problem with a
> particular system.

That would be a GCC error then. I would need to know in what versions
it would be affected in because it is vital for my programs that it
works. As I said, I have written this sort of system twice before and
never had this problem.

> > Effectively, is it impossible to do object-broking in this manner using
> > gcc?
>
> Not safely. There are simply too many things that could go wrong or that a
> malicious plugin could do that it is really hard to check. Why not take a
> component model in the first place if you need these checks?

This is a type of component model, and this particular version is being
run on Solaris. If dynamic_cast is not guaranteed to work the only
other thing I could do would be to have each object identify its type
(or types) and hack the cast with reinterpret_cast (which I'm not sure
is safe in a possibly multiply-inherited hierarchy either).