This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]