This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Another way to salvage Annex K and its constraint handler
- From: Florian Weimer <fweimer at redhat dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, Martin Sebor <msebor at redhat dot com>
- Date: Fri, 20 Nov 2015 21:45:04 +0100
- Subject: Re: Another way to salvage Annex K and its constraint handler
- Authentication-results: sourceware.org; auth=none
- References: <564F3982 dot 5020504 at redhat dot com> <20151120193519 dot GY3818 at brightrain dot aerifal dot cx>
On 11/20/2015 08:35 PM, Rich Felker wrote:
> dlopen is outside the scope, but the behavior of a conforming program
> that just happens to be dynamic-linked rather than static-linked is
> not outside the scope. You cannot just ignore the constraint handler
> set by one function because it happened to be performed from code in a
> different DSO. What DSO the code lies in is an implementation detail.
> And of course such a "solution" does nothing for static linking
> anyway.
I'm not sure if I agree, at least as far as C is concerned. Windows has
much more DLL-local state than we do, and that's not a reason why it's
non-complaint. With a functioning dlmopen, we get much more of such
state, if we like it or not.
We already make many callbacks DSO-local (atexit, pthread_create_key),
so that you don't get segfaults when a DSO is unloaded. The constraint
handler would just be another such callback, but there are other
benefits as well (the locking aspect).
Florian