Re: RFC: fixing signal context namespace issues

[Joseph Myers <joseph at codesourcery dot com>]

On Tue, 2 May 2017, Zack Weinberg wrote:

> > Note the caveats on platforms using "typedef struct sigcontext
> > mcontext_t;": (a) as sigcontext is not a reserved name, the C++ mangled
> > name of mcontext_t would change depending on __USE_MISC,
> 
> ... that sounds like an unacceptable side effect to me.  I would make
> the strong claim that the C++ mangled name of a type must never change
> in response to any user-controlled feature-selection macro, except
> those that have the specific function of selecting alternative
> definitions of a particular type (e.g. __USE_FILE_OFFSET64).

Well, an alternative would be to stop including bits/sigcontext.h from 
sys/ucontext.h (absent __USE_MISC, anyway; the inclusion directly from 
signal.h is already conditional on __USE_MISC), and duplicate the 
definition directly in sys/ucontext.h (with or without having the use of 
__ prefixes on field names conditional on !__USE_MISC), so:

typedef struct { ... } mcontext_t;

That would change the mangled name (from "sigcontext" to "mcontext_t"), 
but as an unconditional one-off change (like that when we eliminated the 
"struct siginfo" name some time ago) rather than depending on feature test 
macros.  Of course that would break things for anyone expecting mcontext_t 
and struct sigcontext to be the same type, but as they aren't the same 
type on x86 I doubt people are depending on equality elsewhere.

-- 
Joseph S. Myers
joseph@codesourcery.com