This is the mail archive of the
mailing list for the glibc project.
Re: Fix mcontext_t sigcontext namespace (bug 21457)
On Tue, 27 Jun 2017, Szabolcs Nagy wrote:
> > diff --git a/sysdeps/unix/sysv/linux/aarch64/sys/ucontext.h b/sysdeps/unix/sysv/linux/aarch64/sys/ucontext.h
> > index 4f602fc..90d0c42 100644
> > --- a/sysdeps/unix/sysv/linux/aarch64/sys/ucontext.h
> > +++ b/sysdeps/unix/sysv/linux/aarch64/sys/ucontext.h
> > @@ -24,10 +24,15 @@
> > #include <features.h>
> > #include <bits/types/sigset_t.h>
> > -#include <bits/sigcontext.h>
> this may break software that rely on declarations from
> asm/sigcontext.h to be visible in sys/ucontext.h (e.g.
> struct fpsimd_context ?), but i don't know if this is
> actually the case.
They can of course include <signal.h> (or <asm/sigcontext.h> directly).
It's possible to keep the include, conditioned on __USE_MISC, just not
clear that's worthwhile.
> i find the c++ abi break problematic.
> i would not expect mcontext_t to be common argument
> in c++ code, but it's a moderately dangerous change,
> while the status quo is not too bad.
For some previous patches in this series, changing stack_t and ucontext_t,
Florian checked there were no affected mangled names in Fedora, as
evidence for such problems being rare. Such a check might be worthwhile
here (remembering that what is being looked for is architecture-specific,
but on x86_64 / x86 the mangled name is already mcontext_t and would not
change because there aren't namespace issues there).
Joseph S. Myers