This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RFC: fixing signal context namespace issues


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]