[Fwd: dlopen regression in 1.7? (or is it just me?)]
Wed Aug 12 15:30:00 GMT 2009
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.
More information about the Cygwin-developers