* RFC: fixing signal context namespace issues
@ 2017-05-02 15:39 Joseph Myers
2017-05-02 15:44 ` Zack Weinberg
0 siblings, 1 reply; 4+ messages in thread
From: Joseph Myers @ 2017-05-02 15:39 UTC (permalink / raw)
To: libc-alpha
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: RFC: fixing signal context namespace issues
2017-05-02 15:39 RFC: fixing signal context namespace issues Joseph Myers
@ 2017-05-02 15:44 ` Zack Weinberg
2017-05-02 15:53 ` Joseph Myers
0 siblings, 1 reply; 4+ messages in thread
From: Zack Weinberg @ 2017-05-02 15:44 UTC (permalink / raw)
To: Joseph Myers; +Cc: GNU C Library
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: RFC: fixing signal context namespace issues
2017-05-02 15:44 ` Zack Weinberg
@ 2017-05-02 15:53 ` Joseph Myers
2017-05-02 16:10 ` Zack Weinberg
0 siblings, 1 reply; 4+ messages in thread
From: Joseph Myers @ 2017-05-02 15:53 UTC (permalink / raw)
To: Zack Weinberg; +Cc: GNU C Library
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: RFC: fixing signal context namespace issues
2017-05-02 15:53 ` Joseph Myers
@ 2017-05-02 16:10 ` Zack Weinberg
0 siblings, 0 replies; 4+ messages in thread
From: Zack Weinberg @ 2017-05-02 16:10 UTC (permalink / raw)
To: Joseph Myers; +Cc: GNU C Library
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-05-02 16:10 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-02 15:39 RFC: fixing signal context namespace issues Joseph Myers
2017-05-02 15:44 ` Zack Weinberg
2017-05-02 15:53 ` Joseph Myers
2017-05-02 16:10 ` Zack Weinberg
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).