Re: RFC: fixing signal context namespace issues

[Zack Weinberg <zackw@panix.com>]

On Tue, May 2, 2017 at 11:53 AM, Joseph Myers <joseph@codesourcery.com> wrote:
> 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.

Modulo details of what goes where, that certainly seems less dangerous
to me, but I think it would still be a good idea to do some sort of
investigation to find out whether anything important will break.  I
don't think these are high-priority namespace issues, so preserving
compatibility seems more important.

zw