This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
RFC: fixing signal context namespace issues
- From: Joseph Myers <joseph at codesourcery dot com>
- To: <libc-alpha at sourceware dot org>
- Date: Tue, 2 May 2017 15:38:56 +0000
- Subject: RFC: fixing signal context namespace issues
- Authentication-results: sourceware.org; auth=none
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