Re: Detecting dlclose() on an already closed handle?

[Szabolcs Nagy <nsz at port70 dot net>]

* Carlos O'Donell <carlos@redhat.com> [2016-12-25 22:10:13 -0500]:
> On 12/22/2016 11:56 AM, Carlos O'Donell wrote:
> > POSIX says:
> > ~~~
> > If the referenced symbol table handle was successfully closed, dlclose() 
> > shall return 0. If handle does not refer to an open symbol table handle 
> > or if the symbol table handle could not be closed, dlclose() shall 
> > return a non-zero value. More detailed diagnostic information shall 
> > be available through dlerror().
> > ~~~
> 
> I read too much into this.
> 
> The only thing the text guarantees is that the handle currently points to
> an open symbol table (loaded library) and we don't care if it originally
> referenced a different library due to handle reuse.
> 
> Therefore the only solution being forced is that the implementation must
> maintain a list of open objects. We already do that for dlopen/dlclose.
> Where it's costly is dlsym where you have to do handle validation.
> 
> Therefore I think we can fix this without much trouble.

yes it can be fixed, my point was that the return value is not
something the caller can rely on in a multi-threaded process.

i still think it's a posix bug to require extra work when the
result is not useful. (even libc calls may dlopen, as they do
in glibc, so the caller cannot reasonably avoid handle reuse
in case of double dlclose).