This is the mail archive of the
mailing list for the glibc project.
Re: Fix mcontext_t sigcontext namespace (bug 21457)
- From: Zack Weinberg <zackw at panix dot com>
- To: libc-alpha at sourceware dot org
- Date: Mon, 26 Jun 2017 17:06:13 -0400
- Subject: Re: Fix mcontext_t sigcontext namespace (bug 21457)
- Authentication-results: sourceware.org; auth=none
- References: <alpine.DEB.email@example.com>
On 06/20/2017 01:53 PM, Joseph Myers wrote:
> This patch continues the ucontext.h namespace fixes by fixing issues
> related to the use of struct sigcontext as mcontext_t, and inclusion
> of <bits/sigcontext.h> even when struct sigcontext is not so used.
I'm concerned that this may be a step too far in the direction of POSIX
conformance at the expense of existing code: specifically, existing code
that assumes that struct sigcontext and mcontext_t are "compatible"
types (in the C-standardese sense), not just structures with the same
set of members. The most _obvious_ ways this would show up are passing
'mcontext_t *' values to functions taking 'struct sigcontext *'
arguments, or using structure assignment to copy between the two, both
of which should cause compile failures; but there could be other
problems (aliasing, perhaps), that only show up at runtime.
struct sigcontext is legacy BSD; I might actually feel better about a
patch that completely removed it (in favor of having <signal.h> define
mcontext_t under __USE_MISC if it doesn't already, which I believe we
are allowed to do, if only by the blanket _t reservation), as that would
be guaranteed to cause compile-time failures for all affected code. If
we go this route, the same change should be made to kernel-provided UAPI
Independent of that, this is finicky enough and has enough
kernel-interface implications that I think it had better have
architecture maintainer reviews for, at least, all architectures where
you copied the contents of struct sigcontext into the definition of