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: Martin Sebor <msebor at gmail dot com>
- Cc: Rich Felker <dalias at libc dot org>, GNU C Library <libc-alpha at sourceware dot org>, Martin Sebor <msebor at redhat dot com>
- Date: Mon, 21 Dec 2015 14:37:19 +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> <564F8650 dot 3080500 at redhat dot com> <20151120213551 dot GZ3818 at brightrain dot aerifal dot cx> <567288CC dot 7000604 at redhat dot com> <5672EC70 dot 9050700 at gmail dot com>
On 12/17/2015 06:10 PM, Martin Sebor wrote:
>> Anyway, I brought this up because I do think that for the Annex K
>> constraint handler, the per-DSO model is much more useful to programmers
>> than the per-thread model. With the per-DSO model, you don't usually
>> have to care about constraint handlers in a library at all. With the
>> per-thread model, you have to set and restore the constraint handler
>> around any use of Annex K functionality, which pretty much kills the
>> entire thing due to inconvenience.
>
> If I understand the per-DSO model you are suggesting, then it
> seems to me that it would work only for threads that run fully
> within the confines of a single DSO.
No, I think it's more general than that. But you can't set a constraint
handler, call a library function (in a different DSO), and have your
constraint handler called on failure. But that doesn't work in general
anyway because the library might use the constraint handler in a
specific way to implement what it needs. (The latter is the reason why
there is discussion about having more than one constraint handler per
process.)
> Otherwise, distinct threads needing their own unique handler
> running code from or more libraries would still have no way
> to avoid stomping on each other's handlers.
With the per-DSO model, you could still install a constraint handler
that wraps around the actual handler, after loading it from a
thread-local variable. But I expect that few libraries will need this.
To clarify, the advantage of the per-DSO model is that you can call
set_constraint_handler_s (abort_handler_s);
from a DSO constructor (because the default handler may not actually
abort the process), and afterwards, call
strcpy_s(buf, sizeof (buf), source);
and get process termination if the constraint is violated.
Under the per-thread model, you'd have to use:
constraint_handler_t old = set_constraint_handler_s (abort_handler_s);
strcpy_s(buf, sizeof (buf), source);
set_constraint_handler_s (old);
I can't see anyone writing code like this. The Annex K functions are
there to retrofit legacy code, and now you have to introduce additional
cleanup paths, which is not a strictly local change. It's just not
worth it.
> But that aside, even if the thread safety problem were solved,
> there are other (IMO more serious and more fundamental) issues
> with the annex that make its future uncertain. At the last
> WG14 meeting where we discussed N1969, in a poll of the
> participants, 9 out of 16 voted to remove Annex K from the next
> C standard. The rest said they would prefer to see it fixed or
> replaced with some better version. I would recommend to avoid
> investing too much effort into it until WG14 decides what to do
> with it.
Understood, thanks.
Florian