This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: [Fwd: dlopen regression in 1.7? (or is it just me?)]
On Aug 12 15:48, Dave Korn wrote:
> Corinna Vinschen wrote:
> > Of course, we could also kludge dlopen to workaround "broken" DLLs.
> > It could store the old cxx_malloc pointer before calling LoadLibrary and
> > restore it afterwards. This would allow us to stick with these DLLs.
> >
> > I tested the below patch to dlopen. It seems to work nicely for the
> > testcase sent by Peter. Any drawbacks?
>
> The only slight drawback is it means that you can't have a malloc override in
> a dlopen'd library, because it restores the pointer without copying back the
> updated set of overrides from the library's internal struct that the pointer now
> points at.
>
> Of course that's good because it means you can't dlclose it and suddenly have
> operator new disappear, but it might be a nice feature. To make it work, we'd
> need to maintain a stack of override entries, so that at dlclose time we could
> restore the previous set of overrides. I'm just pondering if we can figure out
A stack wouldn't help since the dlclose calls can be in arbitrary order.
And there's something else which speaks agains supporting overriding new
in dlopened libs. Consider this scenario:
dlopen(lib1) Installs own new
dlopen(lib3) Installs own new
At this point the new of lib2 will be used for any further call.
But what if lib1 expects that *its* new is used? Isn't the entire
idea to support dynamically overridable allocators quite dangerous?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat