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 16:44, Dave Korn wrote:
> Corinna Vinschen wrote:
> > A stack wouldn't help since the dlclose calls can be in arbitrary order.
>
> Sorry, wrong terminology. I was thinking of a linked list really. It would
> behave mostly like a stack, except in such cases.
>
> > 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?
>
> I don't think lib1 is allowed to expect that. What if the user defined an
> operator new in their executable? That takes priority over the lot, and even in
> static linking that's the case. So I don't think it's legitimate to write
> library code that assumes a particular implementation of operator new is in effect.
>
> > Isn't the entire
> > idea to support dynamically overridable allocators quite dangerous?
>
> Only about as dangerous as the idea to support statically overrideable
> allocators, I think. And yes, ELF is full of this nutso stuff and things do
> dynamically appear and disappear at run time. And I tend to feel that we don't
> want to go down that road. So I think the simple solution of not permitting
> overrides in dynamically opened libraries is probably the right solution, too.
>
> All I'm testing is a slightly tweaked version of your patches with a couple of
> comments added. Do you want to go ahead and check them in, or shall I post the
> complete patch to the -patches list once I've given it a thorough test? They
> look about right to me.
I will wait for your comment-extended version, no worries.
But I'm still not clear on
newu->cxx_malloc = &__cygwin_cxx_malloc;
vs.
*newu->cxx_malloc = __cygwin_cxx_malloc;
What's the better approach now?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat