Re: Fix mcontext_t sigcontext namespace (bug 21457)

[Zack Weinberg <zackw at panix dot 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
headers.

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
mcontext_t.

zw