RFC: fixing signal context namespace issues

RFC: fixing signal context namespace issues

[Joseph Myers]

Various of the remaining miscellaneous XFAILed conform/ tests are for 
namespace issues in signal.h, sys/wait.h and ucontext.h.

As specified by POSIX, "The <signal.h> header shall define the mcontext_t 
type through typedef.".  In turn, this type is included as an element of 
ucontext_t.  However, while various namespaces are reserved for use in 
<signal.h>, the various mcontext_t definitions involve fields that are not 
part of any standard-permitted namespace.

Any comments on the following approach for fixing namespace use from these 
headers?

* Fields with names such as "reserved" or "padding" should be taken not to 
be part of any API, and renamed unconditionally to use the 
__glibc_reserved* convention.

The following changes would then be conditional on __USE_MISC not being 
defined, so the default API remains unchanged:

* Macros, structures etc. (in sys/ucontext.h, and bits/sigcontext.h where 
that is involved in defining mcontext_t / ucontext_t) that are not 
required for defining mcontext_t / ucontext_t would be disabled in the 
!__USE_MISC case.  (Reserved-namespace identifiers would remain 
unconditionally.)

* Structures, structure fields etc. that are not reserved-namespace, but 
that are required for defining mcontext_t / ucontext_t, would be renamed 
to __* conditional on !__USE_MISC (via using some macro to define them 
that adds __ in the !__USE_MISC case).  (If *_t types such as gregset_t 
are used in the definitions, there is no need to rename them because of 
the *_t reservation in POSIX.)

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, and (b) in the 
!__USE_MISC case, each architecture would need to have its own definition 
of struct __sigcontext in glibc rather than being able to use 
asm/sigcontext.h from bits/sigcontext.h as at present on most 
architectures (however, asm/sigcontext.h could continue to be used in the 
__USE_MISC case).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: RFC: fixing signal context namespace issues

[Zack Weinberg]

On Tue, May 2, 2017 at 11:38 AM, Joseph Myers <joseph@codesourcery.com> wrote:
> Various of the remaining miscellaneous XFAILed conform/ tests are for
> namespace issues in signal.h, sys/wait.h and ucontext.h.

Without commenting on anything else ...

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

zw

Re: RFC: fixing signal context namespace issues

[Joseph Myers]

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

Re: RFC: fixing signal context namespace issues

[Zack Weinberg]

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