Re: dlclose()

[Jim Blandy <jimb at zwingli dot cygnus dot com>]

> Well, any reactions, JimB?  We don't have any other solib.c
> maintainers yet.  I also haven't heard from Mark Kettenis recently on
> this issue - I know he was talking about an solib.c rewrite (not
> something I disagree with, really), but that was in the context of a
> rather different patch (even if it addressed the same problem).

I don't think this patch is right.  

For example, when we call find_solib with recheck true, it's difficult
to see that we're not leaking memory.  After the first top-level `if'
which sets lm and so_list_next, if lm is non-zero, we allocate a fresh
`struct so_list' node, and plug it into so_list_ptr->next.  In the old
code, this only happened when so_list_next was zero, so we knew we
were overwriting a null pointer.  But now we do it whenever recheck is
true, even if so_list_next is not zero.  Don't we orphan the old
successor of so_list_ptr?  Perhaps I'm missing something.

Overall, I have a really hard time understanding the logic this would
introduce into find_solib and solib_add.  I would like to see this bug
fixed, but I don't want this code on the trunk, and I don't think we
should drop it into an impending release.